CODEWITHSUNDEEP
gitsvnversion-control
Knuckles the Echidna
Knuckles the Echidna

Reputation: 1737

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

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.

Upvotes: 19

Views: 10389

Answers (2)

randy-wandisco
randy-wandisco

Reputation: 3659

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!

Upvotes: 25

Steve Barnes
Steve Barnes

Reputation: 28405

A couple of things spring to mind.

  1. Git supports private branches which AFAIK SVN doesn't.
  2. Git actively supports workflows where one or more members of the team are developing, possibly propitiatory or confidential branches with commits to the version control and collaboration without between sub-team members without "publishing" the work to the rest of the team(s) and without complex ACL controls to lock some of the branches from being accessible to the remainder of the team.
  3. With git and multiple developers you can always recover your repositories, (or the majority of them), complete with history in the event of a failure short of every developers machine being wiped out - with SVN if something happens to the main server/repository then it is all down to your backup policy.

I am sure that there are many more.

Upvotes: 1

Related Questions