First, incomplete, but promising stab at converting pbranch scenarios to "changeset evolution"

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Thu Sep 1 04:26:00 CDT 2011


On Thu, Sep 1, 2011 at 11:06 AM, Pierre-Yves David
<pierre-yves.david at logilab.fr> wrote:
> On Wed, Aug 31, 2011 at 03:48:01PM +0200, Peter Arrenbrecht wrote:
>
>> >> Transcript:
>> >>
>> >> idank: parren: I've been messing around with this test
>> >> http://paste.pocoo.org/show/464860/
>> >> idank: it looks like there are several things we can do, not sure what's right
>> >> idank: basically the end result needs to be a merge of 3 and 5 which
>> >> will be a new version of patchA
>> >> idank: (we can't merge 6 and 4)
>> >> parren: idank: Heh, that's what I'm thinking about.
>> >> parren: So merging 4 and 6 is going to conflict on a, which merging 3
>> >> and 5 will not, is that it?
>> >> idank: yeah, that's what happened when I tried that
>> >> parren: idank: This is annoying. It's going to get rather complicated
>> >> when both do multiple amends before we merge.
>> >> idank: both as in someone and a collaborator?
>> >
>> > In such case we need merge plumbery to performe a merge between the two conflicting changeset (4 and 6) using their *evolution* common ancestor (1) as base. I'm not sure how this is complicated.
>>
>> Because of:
>>
>> >> parren: So merging 4 and 6 is going to conflict on a, which merging 3
>> >> and 5 will not, is that it?
>
> Not if you use (1) are common ancestor of 4 and 6. After discussion with Idank
> the simplest way seems to make mercurial consider "evolution" relation as "real
> ancestors" relation during such "evol-merge". This way we'll get a simple
> standard merge of difference between 4 and 6 from 1.

This sounds like a can of worms. How do you, for instance, implement
rename tracking properly? I fear we would end up duplicating a lot of
logic that we'd all get for free (and could continue to maintain in a
single place) if we found a way to leverage Hg's existing DAG for
patch evolution.
-parren


More information about the Mercurial-devel mailing list