SVN vs Git

SVN is a minor improvement on the CVS design. A linear, central repository. To their credit, the developers of SVN acknowledge this, from the Red Book:

Subversion was designed to be a successor to CVS, and its originators set out to win the hearts of CVS users in two ways—by creating an open source system with a design (and “look and feel”) similar to CVS, and by attempting to avoid most of CVS’s noticeable flaws. While the result wasn’t—and isn’t—the next great evolution in version control design, Subversion is very powerful, very usable, and very flexible.

Git is a Distributed Version Control System (DVCS). It’s important to distinguish it as “decentralized”. What that means is that each user creates a literal “fork” of the project.

What Git offers that’s important is lightweight branching and significantly better merging. These are what make advanced workflows (feature branches) possible. See Git Flow.

Branching by itself isn’t where the magic is. What makes Git bounds above SVN is actually the merging. What makes the merging so much better is actually how the history of commits is kept. Git is a Directed Acyclic Graph (DAG) and SVN is done linearly.

What this means is the SVN merge doesn’t take into account previous merges of the branch, it merges the files directly. They’re both doing 3-way merges, but the 3rd that is used (the common ancestor) isn’t the same because the linear history of SVN isn’t taking into account previous merges. So basically SVN goes back way further because it doesn’t know where the last merge between branches was. The result is a lot more conflicts that have to be manually resolved.

The above is outdated. As of SVN version 1.5, (2008), SVN includes meta data on merge histories, so it uses the 3-way merge to similar effect as Git now. I’m going to have to write a new one of these after more research.…………

Leave a comment