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