Strategies for push/merge problem?

[Alpár Jüttner]

> But I also use a push workflow: 
> When I work on my laptop, I never merge on it. I only push back my changes 
> onto my desktop and merge there.

This might be a misunderstanding. I didn't mean that 'push' operation is
not necessary.

By the 'pull' approach I mean that every repository/branch has a single
(or very few) owner(s), and they decide on which commit will go to their
repo.
It is my decision to pull changeset into my repo, but it is the
responsibility of the maintener(s) of a software product which
changesets gets into the "official" branch of a software. If you are the
owner of both the source and the target repository, then push and pull
is equivalent.

Therefore (at least for me) the DVC means that the set of people
involving into the development of a software can be (and it is indeed)
very different from those who actually have write access to the central
repository. This approach is what I quite impoliticly called as "true
DVCS way".

In contrast, in a centralized VC, only those having write access can do
commits, therefor a lot of people must have access write to the central
repository, but then they can do any kind of change in the repository
without any control. Also all changes become effective immediately,
preliminary reviewing is impossible.

> And once someone talks about the "true DVCS way", it sounds far too much 
> like "true metal" (music) or "morally right path" (with moral being defined 
> by the society, not the individuum). 

You are right, I'm sorry for this possibly offensive expression. This
meant to be a personal view of DVSC. Please read it as "the opposite of
the centralized approach". See my explanation above.

> So I think, restricting any workflow isn't the way to go. 

You are right, until it does not make the tool more bulky and overly
complex.

Best regards,
Alpar