svn - What makes merging in DVCS easy?

Question

I read at Joel on Software:

With distributed version control, the distributed part is actually not the most interesting part.

The interesting part is that these systems think in terms of changes, not in terms of versions.

and at HgInit:

When we have to merge, Subversion tries to look at both revisions—my modified code, and your modified code—and it tries to guess how to smash them together in one big unholy mess. It usually fails, producing pages and pages of “merge conflicts” that aren’t really conflicts, simply places where Subversion failed to figure out what we did.

By contrast, while we were working separately in Mercurial, Mercurial was busy keeping a series of changesets. And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.

By looking at the SVN's repository folder, I have the impression that Subversion is maintaining each revisions as changeset. And from what I know, Hg is using both changeset and snapshot while Git is purely using snapshot to store the data.

If my assumption is correct, then there must be other ways that make merging in DVCS easy. What are those?

* Update:

• I am more interested in the technical perspective, but answers from non-technical perspective are acceptable
• Corrections:
  1. Git's conceptual model is purely based on snapshots. The snapshots can be stored as diffs of other snapshots, it's just that the diffs are purely for storage optimization. – Rafa? Dowgird's comment
• From non-technical perspective:
  1. It's simply cultural: a DVCS wouldn't work at all if merging were hard, so DVCS developers invest a lot of time and effort into making merging easy. CVCS users OTOH are used to crappy merging, so there's no incentive for the developers to make it work. (Why make something good when your users pay you equally well for something crap?)
     ...
     To recap: the whole point of a DVCS is to have many decentralized repositories and constantly merge changes back and forth. Without good merging, a DVCS simply is useless. A CVCS however, can still survive with crappy merging, especially if the vendor can condition its users to avoid branching. – J?rg W Mittag's answer
• From technical perspective:
  1. recording a real DAG of the history does help! I think the main difference is that CVCS didn't always record a merge as a changeset with several parents, losing some information. – tonfa's comment
  2. because of merge tracking, and the more fundamental fact that each revisions knows its parents. ... When each revision (each commit), including merge commits, know its parents (for merge commits that means having/remembering more than one parent, i.e. merge tracking), you can reconstruct diagram (DAG = Direct Acyclic Graph) of revision history. If you know graph of revisions, you can find common ancestor of the commits you want to merge. And when your DVCS knows itself how to find common ancestor, you don't need to provide it as an argument, as for example in CVS.
     .
     Note that there might be more than one common ancestor of two (or more) commits. Git makes use of so called "recursive" merge strategy, which merges merge bases (common ancestor), till you are left with one virtual / effective common ancestor (in some simplification), and can the do simple 3-way merge. – Jakub Nar?bski's answer

Check as well How and/or why is merging in Git better than in SVN?

Answer 1

There's nothing in particular in DVCSs that makes merging easier. It's simply cultural: a DVCS wouldn't work at all if merging were hard, so DVCS developers invest a lot of time and effort into making merging easy. CVCS users OTOH are used to crappy merging, so there's no incentive for the developers to make it work. (Why make something good when your users pay you equally well for something crap?)

Linus Torvalds said in one of his Git talks that when he was using CVS at Transmeta, they set aside an entire week during a development cycle for merging. And everybody just accepted this as the normal state of affairs. Nowadays, during a merge window, Linus does hundreds of merges within just a few hours.

CVCSs could have just as good merging capabilities as DVCSs, if CVCS users simply went to their vendors and said that this crap is unacceptable. But they are caught in the Blub paradox: they simply don't know that it is unacceptable, because they have never seen a working merge system. They don't know that there is something better out there.

And when they do try out a DVCS, they magically attribute all the goodness to the "D" part.

Theoretically, due to the centralized nature, a CVCS should have better merge capabilities, because they have a global view of the entire history, unlike DVCS were every repository only has a tiny fragment.

To recap: the whole point of a DVCS is to have many decentralized repositories and constantly merge changes back and forth. Without good merging, a DVCS simply is useless. A CVCS however, can still survive with crappy merging, especially if the vendor can condition its users to avoid branching.

So, just like with everything else in software engineering, it's a matter of effort.