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 inte

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.

Answer 2

Part of the reason is of course the technical argument that DVCSes store more information than SVN does (DAG, copies), and also have a simpler internal model, which is why it is able to perform more accurate merges, as mentioned in the other responses.

However probably an even more important difference is that because you have a local repository, you can make frequent, small commits, and also frequently pull and merge incoming changes. This is caused more by the ‘human factor’, the differences in the way a human works with a centralised VCS versus a DVCS.

With SVN, if you update and there are conflicts, SVN will merge what it can and insert markers in your code where it can’t. Big big problem with this is that your code will now no longer be in a workable state until you resolve all the conflicts.

This distracts you from the work you are trying to achieve, so typically SVN users do not merge while they are working on a task. Combine this with the fact that SVN users also tend to let changes accumulate in a single large commit for the fear of breaking other people’s working copies, and there will be large periods of time between the branch and the merge.

With Mercurial, you can merge with incoming changes much more frequently inbetween your smaller incremental commits. This will by definition result in less merge conflicts, because you will be working on a more up-to-date codebase.

And if there turns out to be a conflict, you can decide to postpone the merge and do it at your own leisure. This in particular makes the merging so much less annoying.

Answer 3

I think the DAG of changesets, as mentioned by others, makes a big difference. DVCS:es require split history (and merges) at a fundamental level, whereas I suppose CVCS:es (which are older) where built from day 1 to track revisions and files first, with merge support being added as an afterthought.

So:

• Merging is easy to do and track in when tags/branches are tracked separately from the directory tree of sources, so the entire repo can be merged in one go.
• Since DVCS:es have local repos, these are easy to create, so it's turns out it's easy to keep different modules in different repos instead of tracking them all inside a big repo. (so repo-wide merges don't cause the same disruptions as they would be in svn/cvs where one repo often contains many unrelated modules which need to have separate merge histories.)
• CVS/SVN allows different files in the working directory to come from different revisions, while DVCS:es usually have one revision for the entire WC, always (i.e. even if a file is be reverted to an earlier version, it will show as modified in status as it is different from the file in the checked out revision. SVN/CVS does not show this always.)

Mixing these concepts (as Subversion does) is, I belive, a big mistake. For instance, has branches/tags inside the source tree, so there you have to track which revisions of files have been merged to other files. This is clearly more complex than just tracking which revisions have been merged.

So, summarizing:

• DVCS:es need easy merges, have have their feature set based on that. Design decision where made so that these merges are easy to do and track (via DAG), and other features (branches/tags/submodules) are implemented to suit that, not the other way around.
• CVCS:es had some features from the start (such as modules) that made some things easy, but make repo-wide merges very tricky to implement.

At least this is what I feel from my experience with cvs, svn, git and hg. (There probably are other CVCS:es which has got this thing right too.)

Answer 4

One point is that svn merging is subtly broken; see http://blogs.open.collab.net/svn/2008/07/subversion-merg.html I suspect this is in conjunction with svn recording mergeinfo even on cherry-picking merges. Add a few plain bugs in handling border cases, and svn as the current poster child of CVCS makes them look bad as opposed to all the DVCS which just got it right.

Answer 5

In Git and other DVCS merges are easy not because of some mystical series of changesets view (unless you are using Darcs, with its theory of patches, or some Darcs-inspired DVCS; they are minority, though) that Joel rambles about, but because of merge tracking, and the more fundamental fact that each revisions knows its parents. For that you need (I think) whole-tree / full-repository commits... which unfortunately limits ability to do partial checkouts, and making a commit about only subset of files.

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.

Git use of rename detection was created to be able to deal with merges involving file renames. (This supports Jörg W Mittag argument that DVCS have better merge support because they had to have it, as merges are much more common than in CVCS with its merge hidden in 'update' command, in update-then-commit workflow, c.f. Understanding Version Control (WIP) by Eric S. Raymond).

Answer 6

As a historical note, the now-archaic PRCS system also knows about common ancestors and can merge efficiently, though it wasn't distributed (it was built on top of RCS files!). It meant that it could be effectively migrated to git while retain history, however.