Merge not as expected
mpaesold at gmx.at
Sun Sep 25 13:27:32 CDT 2005
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
I have used a test inspired by an author of subversion with mercurial:
(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:
| \ | # merge, conflict resolved as:
| `---------- one
`----------- # 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
Doing this with mercurial (version 0.7) results in this conflict:
What I don't understand is why the base is chosen as "1\n2\n3\n" here (the
very first changeset). If mercurial remembers the first merge, it should
know that the base must be "one\ntwo\nthree\n" instead.
Is this a mercurial short comming or bug, or did I do something wrong?
I have attached a self-contained test case as bash script. Watch out as it
does a "rm -rf test-a test-b" first.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 746 bytes
Desc: not available
Url : http://www.selenic.com/pipermail/mercurial/attachments/20050925/3b96d912/hg-test.obj
More information about the Mercurial