[Python-Dev] Mercurial workflow question...

[Stephen J. Turnbull]

Raymond Hettinger writes:

 > Does hg's ability to "make merges easier than svn" depend on having
 > all the intermediate commits?  I thought the theory was that the smaller
 > changesets provided extra information that made it possible to merge
 > two expansive groups of changes.

Tim Delaney's explanation is correct as far as it goes.

But I would give a pretty firm "No" as the answer to your question.

The big difference between svn (and CVS) and hg (and git and bzr) at
the time of migrating the Python repository was that svn didn't track
merges, only branches.  So in svn you get a 3-way merge with the
branch point as the base version.  This meant that you could not track
progress of the mainline while working on a branch.  svn tends to
report the merge of recent mainline changes back into the mainline as
conflicts when merging your branch into the mainline[1][2], all too
often resulting in a big mess.

hg, because it records merges as well as branches, can use the most
recent common version (typically the mainline parent of the most
recent "catch-up" merge) as the base version.  This means that (1)
there are somewhat fewer divergences because your branch already
contains most changes to the mainline, and (2) you don't get
"spurious" conflicts.  On the other hand, more frequent intermediate
committing is mostly helpful in bisection, and so the usefulness
depends on very disciplined committing (only commit build- and
test-able code).

Summary: only the frequency of intermediate merge commits really
matters.  Because in hg it's possible to have frequent "catch-up"
merges from mainline, you get smaller merges with fewer conflicts both
at "catch-up" time and at merge-to-mainline time.


Footnotes: 
[1]  Not the whole story, but OK for this purpose.  Technical details
available on request.

[2]  I have paid almost no attention to svn since Python migrated to
hg, so perhaps svn has improved merge support in the meantime.  But
that doesn't really matter since svn is merely being used to help
explain why commit granularity doesn't matter much to hg's merge
capabilities.