Thursday, December 31, 2009

Why everyone should be using Git...


I'm sure this has all been said before, but people don't seem to get the message: Subversion sucks for external contributors. Occasionally I send some patches for projects using Subversion...

Subversion has no way to commit local patches so that you can test out your changes, split up commits functionally, generate patches easily so you can send them to a review list, or any of these great features. Git does not have this problem; in fact it has a very nice set of tools for working this way. I won't go into the details of that, as most readers probably know it already, other than saying that it's amazingly simple and easy.

The pain comes when you're an outside contributor for a Subversion project: you might be testing some experimental changes that you don't want to commit to the public repository. Okay, you can edit the files and svn diff locally but this pathetic compared to the power of git commit and git format-patch
  1. You're stuck doing one functional change, and only one functional change. Because you have no way to create a patch series. It's either everything in one commit, or nothing at all.
  2. Even when you have commit access, often this results in multiple functional changes being squashed into a single commit. This is very bad.
  3. Subversion provides no way to add commit messages or authorship to the diff generated by svn diff, so contributors are left out in the cold.
    • Yes, if you have commit access you can provide this meta-data, but you're still pushing directly to the repository with no review what-so-ever.
I could continue, but I think my point is made: Subversion sucks for distributed development (in the across the globe sense) and it also sucks for development in the "few developers distributed across the room" sense. It all adds up to pain and inefficiency: especially for external contributors, but even for people working with the project with commit access.

Thankfully Sourceforge does at least provide rsync access to the Subversion and CVS repositories so git svn clone can be both fast and bandwidth efficient. Unfortunately, however, it seems that Subversion chokes on anything but patches generated by Subversion itself (including standard GNU diff format.)

Everyone should be using Git (or at least some distributed version control system with similar features.)

2 comments:

  1. How do you make git-svn work with the remote repo but use the local copy in the initial import?

    ReplyDelete
  2. Good question, for example, you can clone from Sourceforge as follows:

    rsync -av foobar.svn.sourceforge.net::svn/foobar/* rsync
    git svn clone file://$(readlink -f rsync) foobar

    Sorry about the lack of monospace font, but Blogspot doesn't seem to allow this in comments. After the initial clone, all you have to do is edit .git/config and change the url argument under [svn-remote "svn"].

    git svn rebase should then work as normal, using the live Subversion repository. Note I haven't actually tested this myself, though.

    I still maintain it's more bandwidth efficient to have a cron job and a script which updates the rsync directory and rebases daily.

    ReplyDelete