History senstive merging?

Giorgos Keramidas keramida at ceid.upatras.gr
Fri Dec 12 03:11:49 UTC 2008


On Thu, 11 Dec 2008 13:55:42 -0500, Neal Becker <ndbecker2 at gmail.com> wrote:
>Giorgos Keramidas wrote:
>> On Thu, 11 Dec 2008 13:33:21 -0500, Neal Becker <ndbecker2 at gmail.com>
>> wrote:
>>> What do you recommend for history sensitive merging?
>>>
>>> I have a file A, which I copied and modified into B.  Now I want to
>>> take the updates to A and apply them to B.  What 3-way diff tool is
>>> good for this?
>>
>> If you used "hg copy A B" to perform the copy this will happen
>> automatically with _any_ merge tool.
>
> Is hg copy appropriate for the case where A and B are intended to
> really be different files?  In my case, A & B are 2 python scripts
> that I want to always be different - yet they have common ancestry and
> features.

If they have common features, and they share parts of their code, then
yes, it probably makes sense to "hg copy".  This way, the history of
each file will have a common 'ancestor change', i.e.:

  A    [1]---[2]---[3]

  B    [1]---[2]---[3]---[4]---[5]

because you used "hg copy A B" and then "hg commit" to produce change
[4], made some changes and then committed change [5].

If you clone the repository at change [3] and fix a bug in file A:

  A    [1]---[2]---[3]---[X]

  B    [1]---[2]---[3]---[4]---[5]

pulling into your integration clone and running "hg merge" will attempt
to merge the [X] bugfix to *both* files:

  A    [1]---[2]---[3]---[X]

  B    [1]---[2]---[3]---[4]---[5]
                     \
                      `----[X]

Each file is merged separately, so when you pull change [X] and try to
merge, file A is simply updated to version [X].  But file [B] will be
merged in your 3-way merge tool using change [3] as the 'ancestor'
change.

How useful this will be is, of course, highly debatable, and it depends
on how much file B has diverged from its original version [3] code.  If
the [X] bugfix is not relevant to file B anymore, you can ignore the
change.  But if it *is* relevant, because it affects the shared code of
A and B, it is sometimes nice to get a chance to fix the bug in all the
places where it appears :-)




More information about the Mercurial mailing list