svn - What makes some version control systems better at merging?

Question

I've heard that many of the distributed VCSs (git, mercurial, etc) are better at merging than traditional ones like Subversion. What does this mean? What sort of things do they do to make merging better? Could those things be done in a traditional VCS?

Bonus question: does SVN 1.5's merge-tracking level the playing field at all?

Answer 1

SVN's merging capabilities are decent, and the simple merging scenarios work fine - e.g. release branch and trunk, where trunk tracks the commits on the RB.

More complex scenarios get complicated fast. For example lets start with a stable branch (stable) and trunk.

You want to demo a new feature, and prefer to base it on stable as it's, well, more stable than trunk, but you want all your commits to be propagated to trunk as well, while the rest of the developers are still fixing things in stable and developing things on trunk.

So you create a demo branch, and the merging graph looks like:

• stable -> demo -> trunk (you)
• stable -> trunk (other developers)

But what happens when you merge changes from stable into demo, then merge demo to trunk, while all the time other developers are also merging stable into trunk? SVN gets confused with the merges from stable being merged twice into trunk.

There are ways around this, but with git/Bazaar/Mercurial this simply doesn't happen - they realize whether the commits have already been merged because they ID each commit across the merging paths it takes.