Strategies for push/merge problem?

[Henryk Gerlach]

Hi Roman, 
> Of course you are absolutely correct. But you have to keep in mind, that
> transitioning from one SCM to another (HG in this case) is much less a
> technological problem than a social one. What you describe above is
> ...
> And it has to be said, the way CVS and Subversion handles these things
> has one big advantage: it is perfect for lazy people. All the
Did you ever consider the posibility that hg may not be the right tool for you, your team or the way you work then?

In hg merges are explicit (with exception of a local hg up, which is considered dangerous). This has the advantage that you can ensure certain things on each changeset (see some other part of this thread). If you want to review (or test or do whatever takes some time) the merge before committing the push-model will never scale.

If you're willing to have unreviewed merges you could do something like the following:

you make two repos: incomming and mainline.
The developers always pull from mainline and always push to (using push -f) incomming possibly creating new heads in incomming. Then you set up some process pulling new changes from incomming, merging what it can merge and pushing the changes to mainline.
You will see loads of trvial merges (if your developers push each commit seperately), but that's the development model you chose.

 -Henryk
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser