SVN supports historical merges so how is Mercurial better?

Question

Possible Duplicate:
Merging: hg/git vs. svn

Hi,

I'm a long time SVN user and have been hearing a lot of brou ha ha with regard to mercurial and decentralised version control systems in general. The main touted feature that I am aware of is that merging in Mercurial is much easier because it records information for each merge so each successive merge is aware of the previous ones.

Now as stated in the red book, in the section to do with merging, SVN already supports this with mergeinfo. Now I have not actually used this feature (although I wanted to, our repo version wasn't recent enough) but is this SVN feature particularly different to what Mercurial offers?

For anyone who is not aware the suggested work flow for historical merging in svn is this:

1. branch from the development trunk to do your own thing.

2. Regularly merge changes from trunk into your branch to stay up to date.

3. Merge back when your done with the mergeinfo to smooth the process.

Without historical data merging this is a nightmare because the comparison is strictly on the differences in the files and does not take into account the steps taken on the way. So each change in the development trunk puts you further into possible conflict when you merge back.

Now what I would like to know is:

Does merging using Mercurial provide a significant advantage when compared with mergeinfo in SVN or is this just a lot of hot air about nothing?

Has anyone used the mergeinfo feature in SVN and how good is it actually in practice?

Answer 1

As mentioned in the comments, this SO question pretty much sums it up, but it bears pointing out the exact Subversion (1.6 latest!) documentation stating the merge limitation:

• Basic Merging (sic) / Reintegrating a branch:

    svn merge --reintegrate ^/branches/my-calc-branc

once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again.

What? If you did work some more on that branch since the last merge back to trunk, you can no longer make a second --reintegrate merge?
You have to create another branch or use a cherry-picking syntax with yet another option to keep it alive.

• Advance merging

The conclusion tells you all you need to know:

The bottom line is that Subversion's merge-tracking feature has an extremely complex internal implementation, and the svn:mergeinfo property is the only window the user has into the machinery. Because the feature is relatively new, a numbers of edge cases and possible unexpected behaviors may pop up.

For example, sometimes mergeinfo will be generated when running a simple svn copy or svn move command.

• Sometimes mergeinfo will appear on files that you didn't expect to be touched by an operation.
• Sometimes mergeinfo won't be generated at all, when you expect it to.

Furthermore, the management of mergeinfo metadata has:

• a whole set of taxonomies and behaviors around it, such as “explicit” versus “implicit” mergeinfo, “operative” versus “inoperative” revisions,
• specific mechanisms of mergeinfo “elision,”
• and even “inheritance” from parent to child directories.

Let's compare that to a DVCS:

Just merge already ;)

That doesn't mean SVN doesn't know how to merge (for simple merge workflow, it will do the job), but the complexity of its underlying mechanism will restrain in effect the usage of branches and merges, making the few merge left fairly trivial.
By contrast, the ease of merging operations in DVCS will increase the usage of branches and the complexity of merge scenario, which are no longer a problem.