How is SVN v 1.8 branching / merging compared to Git?

Question

I have been using Git for a while now, and have been recently asked why its merging and branching capabilities are better than those of SVN. Years ago, when I used SVN, I found that branching and merging were quite cumbersome and error prone operations. As a result, I barely branched. However, just last week I tried the new SVN 1.8 version, and I found out that it was doing things quite nicely.

I actually tried some complicated branching stuff and I got no funny errors. Of course, it was tremendously slow, but my main concern is about functionality, not speed (at least when trying to convince someone).

So my question is how much different are SVN v1.8 and Git branching/merging capabilities. In particular, I would also be interested to know if there is some branching and merging operations (or workflow) that can be accomplished with Git but not with SVN (or maybe it can be accomplished with SVN but it is quite difficult).

Thanks.

Answer 1

It's important to understand the model that the Subversion merge engine uses. It's very different from Git.

Subversion supports two basic types of merges. The first is a 'sync' merge that is done to keep a development (feature/task/topic) branch up to date with trunk. The second is a 'reintegrate' merge that is used to promote finished work to the trunk. So the model is a mainline (trunk) model that supports feature branches and release branches.

An important limitation is that Subversion does not consider the full DAG when searching merge history to find the right merge base. Merging between directly related (parent-child) branches is well supported, but merges done between branches that are distant ancestors or siblings, with contributions coming in indirectly from other branches, will often give surprising results.

Subversion merge support is improving over time as you noted. It had no merge tracking at all until 1.5, made huge leaps in 1.8, and the upcoming 1.9 will improve rename/move tracking. There's also talk of 'local shelves' in the future.

(By the way, I know some of this because I attended the Subversion/Git Live conference last week and the committer who works on the merge engine gave a presentation.)

Git on the other hand has a very well respected merge engine. It can handle merges of almost any complexity. In fact its only major merge limitation is that it deduces move/renames after the fact. In very complicated refactoring situations it may not pick up everything properly.

To summarize:

• Both Subversion and Git will work well in common merge scenarios.
• Git will handle more complicated merge scenarios more effectively, particularly when merging between branches that don't have a direct parent-child relationship.
• Both systems have problem with tracking renames/moves during refactoring, although Git probably does a better job in typical cases.
• Git's merge command are easier to run in simple cases. Both systems can have a steep learning curve if you're doing unusual operations.
• Git supports related operations like rebasing and merging between repositories that can improve your workflow in some cases.
• To get the best use out of Subversion, make sure you have 1.8+ server and clients.

Hope that helps!