Merge not as expected

[Matt Mackall]

On Sun, Sep 25, 2005 at 08:27:32PM +0200, Michael Paesold wrote:
> Hello Matt and all,
> 
> I just tried mercurial for the first time (because mercurial is used for 
> xen development) and I am quite impressed. Compared to many other SCMs this 
> is a really usable systems even after such a short time of development 
> (compared to many others!). And compared to even more systems, the 
> architecture is really great.
> 
> I have used a test inspired by an author of subversion with mercurial:
> http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
> (example down on that page)
> 
> The test is modified a little bit from the sample above. There is one file 
> initially containing "1\n2\n3\n", which is than modified in two branches:
> 
> Branch A:      Branch B:
> 1
> 2
> 3
> |`-------------\
> |              |
> one            1
> two            2.5
> three          3
> |\             |
> | \            | # merge, conflict resolved as:
> |  `---------- one
> |              two-point-five
> one            three
> two-point-one  |
> three          |
> \             |
>  \            |
>   `-----------  # merge again
> 
> The interesting point is at "merge again". What should happen in the 
> optimum case is that only the "two..." line is put in conflict markers, the 
> "one" and "three" line should be in all inputs of the three-way merge. This 
> works e.g. with SVK (a distribution extension to subversion) and, according 
> to the information given in the URL above, also in ClearCase. I guess in 
> many others.

Should work here too, but there seems to be a bug:

hg update --debug -m tells us:
...
file test.txt: my fc3148072371 other d40249267ae3 ancestor 01365c4cca56

And hg debugindex .hg/data/test.txt.i tells us:

   rev    offset  length   base linkrev nodeid       p1           p2
     0         0       7      0       0 01365c4cca56 000000000000 000000000000
     1         7       9      1       1 7b013192566a 01365c4cca56 000000000000
     2        16      15      2       2 8fe46a3eb557 01365c4cca56 000000000000
     3        31      27      2       3 fc3148072371 7b013192566a 8fe46a3eb557
     4        58      25      4       4 d40249267ae3 8fe46a3eb557 000000000000

So it looks like there's a lurking bug in the ancestor algorithm still.

I'll try to sort this out tomorrow.

> I have attached a self-contained test case as bash script.

Thanks! Your test was 95% of the way to being in the correct for for
the standard test suite. When I get this bug fixed, I'll check in your test.

-- 
Mathematics is the supreme nostalgia of our time.