Strategies for push/merge problem?

Arne Babenhauserheide arne_bab at web.de
Wed Jul 30 00:15:10 CDT 2008


Am Mittwoch 30 Juli 2008 01:05:48 schrieb Douglas Philips:
> On or about 2008 Jul 29, at 5:56 PM, Chuck.Kirschman indited:
> > reject them in case of conflict.  And in that case, we may as well
> > have
> > Hg support a push model where if your changes do not conflict it does
> > the merge automatically.  So I agree with the corporate crowd that
> > this
> > is the right way to go.
>
> If you think the SVN model is the right one, what is the point of
> picking a tool (Hg) that has made a fundamentally different decision
> about how source control works and then asking them to undo that
> decision? Bored with your perfect workflow? :)

The option to change things later on and incrementally without any hassle. 

Quickly passing on changesets to peers for a quick review before pushing them. 

Fast and offline commits. 

... and much more ...

did I overlook some irony or such? The answer was too clear for me, so I 
suspect there must be something wrong with my understanding of the 
question :) 

If Hg had really made a clear decision how Source control works, whyn would 
pushiong be possible at all? 

Hg can do many different workflows, and limiting it to only the pull workflow 
in our minds will just diminish it. Why not let users find out what _they_ 
want to do with their new freedom? 

Best wishes, 
Arne
-- 
-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software. 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20080730/dc1d606e/attachment.pgp 


More information about the Mercurial mailing list