Thinking about version control

A while back, Django core developer James Bennett set off a bit of a nerd explosion when he publicly questioned whether distributed version control systems like git or Mercurial offer enough advantages over centralized version control systems like Subversion to justify using them in its place. While I'm only experienced with Subversion and git (and my thoughts will be limited to those two systems) this post should serve as my take on version control at large.

My history with version control

I have used Subversion for nearly all programming projects at my day job for the past few years. I manage all of my repositories on an offsite server (my Dreamhost server, actually) and it serves me well as both a version control system and a great offsite backup solution. Working on a development team of one, all of my changesets are simple (no merging necessary).

As for git, I first began working with it a few months back after a some friends set up a Github repository for an excellent javascript tower defense implementation. After coming up with a few small patches, I setup my first Github account and struggled through the process of learning an entirely new set of commands to merge what amounted to a few lines of code. A few projects and many more commits later and I'm much more comfortable with the various git commands.

Why distributed matters

My needs are vanilla enough that Subversion should work well for anything I have going on, yet I now prefer working with git. Instead of giving you a huge narrative, I deem it proper to list off the reasons why a DVCS works best for me:

• No need to setup a server - While the initial setup of git might be complicated, I no longer have to login to my remote server to initialize repositories. This low barrier to entry is a huge win for me.
• You always have the whole tree at your disposal - No need to go back to the server for diffs and the like--each team member (or at least each of your development machines) has the entire repository sitting on the file system. This is also useful in that a server can fail, temporarily or permanently, and you'll still have a complete copy of your repository. It also matters because...
• Local commits (aka offline commits) - You might not realize you need these, but you do. Why should it matter whether you've paid TMobile $10 when you want to add a changeset? Just add and commit whenever and push the stuff up when you get back to a wired location. I find myself breaking commits up into smaller and more specific changesets.
• Branching works - The last thing I would want to suggest is that branching in Subversion does not work, but it always felt like too much work for me. In git, the concept of branching is key, with every copy of the repository basically representing a branch. Having multiple branches in the repository is also a snap, and since you have the whole repository at hand, it is easy to switch between branches as well.

So while I'm a bit late to this conversation, that's my take on the matter.