[Scons-dev] Mercurial and the current SCons workflow are incompatible?

[Martin Geisler]

Russel Winder <russel at winder.org.uk> writes:


> Gary,

>

> This seemingly just gets worse.

>

> From: http://mercurial.selenic.com/wiki/Backout

>

>         Warning

>         

>         Backing out a merge will lead to trouble if you ever want to

>         redo the merge. The only safe way to deal with a bad merge is to

>         abandon the branch.

>

> I think the corollary of this for the SCons workflow is "we're screwed".


I believe I added that warning :) And the example on the wiki page
should show that this behavior is a consequence of how three-way merges
work -- as far as I remember.

As a side remark: It would be good if someone could write the Mercurial
mailinglist (mercurial at selenic.com) with a summary of what's wrong and
how to proceed -- there's a lot of clever people there, including Matt
Mackall who designed Mercurial.


Reverting a published merge is hard (I believe it's hard in Git too).
That is one reason why premature merging is really bad: you *commit*
yourself to the result in a strong way.

One way to "fix" a merge in Mercurial is to abandon it: redo the merge
(correctly this time) and abandon the bad merge:

  $ hg update "p1(bad-merge)"
  $ hg merge "p2(bad-merge)"
  $ hg commit -m "Better version of bad-merge"
  $ hg update bad-merge
  $ hg commit --close-branch -m "Use <new-merge> instead"

That will leave you with a dangling topological head, but that is fine
with modern Mercurial. People who have local work based on bad-merge
will simply rebase it to new-merge and push.

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/scons-dev/attachments/20121015/4d4eb4c5/attachment.pgp>