When you merge in Mercurial it's able to trace through the revision history of a file in the source and target branches, find the common revision, then separate

When you merge in Mercurial it's able to trace through the revision history of a file in the source and target branches, find the common revision, then separately apply the diffs from the source and target branches... Originally subversion couldn't do this, but it has had merge tracking since version 1.5 (a couple of years already). You can now merge one branch into another multiple times without specifying explicitly which revisions to compare. I have seen a number of people saying that the merge tracking in subversion still isn't as good as what's in git or mercurial, but I haven't found an explanation of the difference. Can someone elaborate, or point me to some good reading? lallysingh and nollidge point out that in a DVCS model you tend to make more frequent commits, because committing and publishing are no longer the same action, and that having finer-grained commits makes automatic merging more likely to succeed. This seems quite plausible to me, but it's orthogonal to the problem of merge tracking (isn't it?).