Hi, I've been surprised to find that 'hg merge' does not start a manual merge (via gypfm, filemerge, or whatever your .gfrc selects) for *every* file that is in conflict (i.e., has a status change in both branches). It appears to believe the differences are simple enough (I think defined as "no overlapping or adjacent edits) that it will do the merge for me; not surprisingly, this can go badly wrong.
Based on ON devleopers' past experience with Teamware I think there is a very substantial opportunity for mismerge here, i.e. folks with habits formed under Teamware would be forgiven for thinking all conflicts are resolved once they have handled everything 'hg merge' pops up. I just "completed" an hg merge where 30 files are in conflict (changed in both branches) but only 13 popped up for interative merge while the remainder were rather silently automerged - in around 8000 lines of change it would be quite possible to miss resulting errors. Fortunately I had manually generated a report on all files common to each branch and am keeping notes on merge actions on each file. A demo below outside of ON: 1) Create our main gate repo: (gavinm at enogas:~ )-> cd /tmp (gavinm at enogas:/tmp )-> mkdir repo (gavinm at enogas:/tmp )-> cd repo (gavinm at enogas:/tmp/repo )-> cp /etc/group afile (gavinm at enogas:/tmp/repo )-> hg init (gavinm at enogas:/tmp/repo )-> hg add afile (gavinm at enogas:/tmp/repo )-> hg commit -m "initial repo" 2) Clone two competing child repos: (gavinm at enogas:/tmp/repo )-> cd .. (gavinm at enogas:/tmp )-> hg clone repo child1 updating working directory 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (gavinm at enogas:/tmp )-> hg clone repo child2 updating working directory 1 files updated, 0 files merged, 0 files removed, 0 files unresolved 3) child1 adds a line at the top of 'afile' and pushes the change back. (gavinm at enogas:/tmp )-> cd child1 (gavinm at enogas:/tmp/child1 )-> echo "top" > /tmp/tmpfile (gavinm at enogas:/tmp/child1 )-> cat afile >> /tmp/tmpfile (gavinm at enogas:/tmp/child1 )-> cp /tmp/tmpfile afile (gavinm at enogas:/tmp/child1 )-> hg diff diff -r b32a060e1a43 afile --- a/afile Mon Aug 25 10:55:24 2008 +1000 +++ b/afile Mon Aug 25 10:59:47 2008 +1000 @@ -1,3 +1,4 @@ +top root::0: other::1:root bin::2:root,daemon (gavinm at enogas:/tmp/child1 )-> hg commit -m "add line at top" (gavinm at enogas:/tmp/child1 )-> hg push pushing to /tmp/repo searching for changes Are you sure you wish to push? [y/N]: y adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files 4) child 2 adds a line at the bottom of 'afile': (gavinm at enogas:/tmp/child1 )-> cd ../child2 (gavinm at enogas:/tmp/child2 )-> echo "bottom" >> afile (gavinm at enogas:/tmp/child2 )-> hg diff diff -r b32a060e1a43 afile --- a/afile Mon Aug 25 10:55:24 2008 +1000 +++ b/afile Mon Aug 25 11:01:38 2008 +1000 @@ -22,3 +22,4 @@ nobody::60001: noaccess::60002: nogroup::65534: +bottom (gavinm at enogas:/tmp/child2 )-> hg commit -m "add line at bottom" 5) child2 needs to sync with the gate: (gavinm at enogas:/tmp/child2 )-> hg pull -u pulling from /tmp/repo searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) not updating, since new heads added (run 'hg heads' to see heads, 'hg merge' to merge) 6) 'hg merge' does not require a manual merge of these two changes: (gavinm at enogas:/tmp/child2 )-> hg merge merging afile 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) [No interactive merge required - command completes in an instant] I would *very* much like to have more interaction than that! I don't think it matters, but I have the following in ~/.hgrc related to merge: [merge-patterns] ** = filemerge [merge-tools] filemerge.gui=True filemerge.executable = /opt/teamware/bin/filemerge filemerge.args=-a $base $local $other $output filemerge.checkchanged = true A truss -f on hg merge confirms it doesn't run filemerge here, so it's not filemerge exiting on full automerge - seems all within hg. Gavin
