Strategies for push/merge problem?

Hans Meine meine at informatik.uni-hamburg.de
Tue Jul 15 06:35:48 CDT 2008


Am Dienstag, 15. Juli 2008 13:14:07 schrieb Benjamin Smedberg:
> Yes, but for a project with thousands of active developers, merges are
> mentally much more complex. What most of our developers care about is the
> history of what our tinderboxes built, which was "the tip of
> mozilla-central". When branch/merges are pushed, it's not always clear
> where mozilla-central was, and reading diffs between revisions becomes more
> complicated.
>
> We have work underway to remedy this situation, see e.g.
> 
http://developer.mozilla.org/en/docs/Mercurial/Desired_Features#hgweb_requirements

Very interesting.  So mercurial will eventually get an extension that does 
what bazaar has built-in, and what has confused many projects/people:
http://vcscompare.blogspot.com/2008/06/on-mainline-merges-and-fast-forwards.html

Fernando Perez has summarized the problem he saw in the context of IPython 
lately in the "Bazaar on OS X" thread on ipython-dev as follows:
> I have to say that I've given up on the whole 'history folding'
> problem, so I'm not 100% happy with bzr/lp either.  Basically if you
> have truly diverged lines of work where you did work and committed
> locally while other devs pushed, a merge is inevitable (even if you
> keep several branches and push only from one that you don't develop
> in).  And at that point, bzr does the whole 'dropped revisions' dance
> and folds history.
(There were lots of discussions of this on ipython-dev recently.)

AFAICS the main problem people have with this bzr feature is that the 
so-called "mainline" displayed on launchpad changes in a way that is more or 
less out of control even of developers as Fernando.  Hopefully the 
corresponding mercurial extension will be more transparent.

-- 
Ciao, /  /
     /--/
    /  / ANS


More information about the Mercurial mailing list