Thursday, March 04, 2010

Why I'm leaving Subversion for Git

I always believed in Subversion's potential and that it would be a wide improvement over the nightmare that was CVS, but I found out that, as Linus says, There is no way to do CVS right.
Subversion is fairly good and it's probably the better centralized version control system on the market, and it's open source. But after my first day of Git real-world usage, I now cannot negate that the distributed model of Git will be superior at last.

For example, in Git, you are not forced to have a remote repository: you can start with your local repository, and commit to it. No need to set up server software if you don't want to, as your machine is already your own server.
After working locally for some time and having done very fast commits as you usually did much more slowly with your remote Subversion server, you can push or pull changesets to other repositories. I was worried about the inherent uncertainty in this process (which branch? Which repository?), but Git tracks the origin of your repository, precisely the common ancestor in the remote branch, which your master branch was forked from. When you start by cloning a remote repository (as it is almost always the case), it will push to that origin. But you can also push to nearly everything, even if there is not a common ancestor.
The converse is true: you can also pull to update your repository from an external one, that may be your point of convergence. Obviously, you can also pull from everywhere, in a local branch if you are not sure to incorporate the changes.

The commit access notion vanishes in Git. You and I typically do not have commit access to major projects such as Zend Framework or Doctrine anyway (ok, I have to Doctrine, but when I come out with a small patch I just put it the bug tracker for a review), and we have only our working copy, having to upload patches to the bug tracker. Multiple versions of those patches. That quickly become not in sync with the current revision of the codebase.
Collaboration between working copies is difficult, as an official branch is needed. Moreover, it's rare that you know a branch is needed ahead of time. If for every feature you started a remote branch, even with Subversion (which has cheap copy-on-write branches) the development would be very slow. So many times you end up working on the trunk and struggling because you cannot break it, and sending patches by email. These problems are described in Linus's talk at Google about Git - which is amusing. When I watched his talk using Subversion really started bugging me; I knew that here was an alternative, and it consisted of mature software since the talk was old, from 2007.
What's the solution then? In Git everyone has his own repository, so you can just pull changes from other people and pushing changes to them. There is no commit access, only a group the lead developer trusts and he will pull from. This group may pull and review from other people, in a hierarchical work flow where a chain of trust is established. For an open source project, Git is worth its weight in gold (which actually I don't know, but it will be surely expressed in hexadecimal.)
You can break your repository if you want, committing all the day without problems, and being able to revert to every commit's revision as if Git were a time machine, and very cheaply (in Subversion you are forced to hit the network to revert to revisions older than the last commit.) When you have fixed your copy after ten, twenty or an hundred commits and all tests are passing, you may finally push. Awesome.

And this was only my first day in Git!

9 comments:

e.s.t said...

I did switch from SVN to Mercurial not so long ago, and oh boy it was so eye opening. Anyway, every distributed SCM is a great peace of software, name it Git, Mercurial, Bazaar. The choice between them is a matter of your needs and workflows.
If anyone is interested in Mercurial, see http://hginit.com/.

Kami said...

I've recently switched most of my stuff from SVN to GIT as well.

I really like some of the distributed version control systems ideas, but I'm already looking to an alternative (Mercurial) since I had some strange problems with subtree merges in GIT recently.

On branching is also a good post which made me thinking about switching or at least trying Mercurial in the future.

It's annoying to switch to another VCS when you finally got used to some specific features in the VCS you currently use, but in this case it might be worth it, so I will definitely try some of the more advanced stuff in Mercurial in the future.

P.S. I might be a bit biased towards Mercurial since most of it is written in Python which I love

Bogdan said...

I have to disagree with you on the local repository issue.

I've been using local SVN repositories for some time now, with no problems.

Giorgio said...

I have not tried Mercurial but Fowler says it and Git are the only one quality DVCS.
@Bogdan: do you mean using svnadmin and file:///? You' re right that this can substitute the usage of a server. Though, it's not the same than using Git, I wouldn't know how to merge a local repository into a remote one. :)

Anonymous said...

mercurial is really nice and usable - you should give it a try...

anyway, good step moving away from that painful svn

Sudheer said...

The more articles like this I read about git and hg, I am more provoked to move away from svn.

Subversion has been working well for us. Sometimes, I ask myself, do you even write code without connecting to the Internet?

Giorgio said...

In what sense? Writing is not the slow part, committing is. :)

AdamB said...

I knew that you'll like git, as I did ;) IMHO git is so natural for Linux user, not mention how handy it is (i.e. versioning /etc directory).

Anonymous said...

I tried Git, and ran screaming away. Biggest pain is merging changes from various developers and Git makes it even way more complicated then SVN.

ShareThis