A Subversion User Looks at Git - Part 2

Because I accidentally left comments off on my original Git post, I got a number of responses by email, which I appreciate very much. I'd like to summarise them here and clarify some of my original comments.

Firstly, I didn't intend the phrase "nerdiest of SCM nerds" to be in any way an insult.

On Being Distributed

A number of people felt that I hadn't put enough emphasis on the fact that Git is a distributed SCM system. The fact that most of my projects are closed source and only I work on them probably leads me to care a little less about this feature than others might. I'm interested in distributed SCM more for its ability to allow me a smoother workflow between my desktop and laptop than for the collaboration possibilities. I don't minimise the value of this feature, I just see different advantages in it.

As I see it, the main advantage to distributed SCM is that, for large projects, you don't have everyone's branches cluttering up the central repository. For me, this isn't the huge win that others will see it as, since I don't collaborate with large numbers of people. In any project that shares its code publicly, you still need the concept of a 'canonical' (if no longer a 'central') repository.

Reverting Commits in Git

Another correspondent asked what I meant when I praised Git's ability to "revert a commit", when you can already do something similar in Subversion. The difference is that, With Subversion, you have to undo the effect of a commit by making another commit. With Git, you can completely throw away the last commit you made and pretend that it never happened. However, if someone else has pulled from you before you removed a commit, that's Bad.

Several people mentioned that SVK can add the ability to commit whilst disconnected to Subversion.

Opaque Collections

David Glasser, a contributor to Subversion, suggested that there may be a reworking of the SVN working copy format in the 1.6 timeframe to have one .svn directory in the root of the working copy. Whilst this would be welcome, Bill Bumgarner hits the nail on the head when he says that the true problem is a lack of support for opaque collections.

Since I wrote Part 1 and read Bill's post, I've realised that Git's lack of dot-directory litter only solves part of the problem. What happens if you merge a branch in which someone has changed a NIB bundle's classes.nib file and another developer has changed keyedobjects.nib? The outcome is likely a clean automatic merge that silently results in a broken NIB.

The Externals Problem

I still haven't seen a technique that will replace svn:externals in Git. Wincent Colaiuta discusses using separate checkouts and symlinks, but I really like being able to check out a buildable working copy, with all dependencies, with one command.

Graeme Mathieson commented that Piston is a nicer approach to handling 3rd party code than svn:externals. Piston seems to be a set of wrapper scripts on various Subversion operations that formalise a particular means of importing 3rd party code. It depends on Subversion, however, so it's not a solution for implementing svn:externals in Git.

Am I Switching?

Not today. Switching SCM systems is a huge commitment and it's still early days for most distributed SCMs out there. I'd like to switch to the one that's going to become commonplace, but I'm not able to decide which system that will be yet.

One of the big victories for Subversion has been that it largely had no competition when it first reached usable status and everyone adopted it. This leads to a good return on one's time investment in learning Subversion.

I'm certainly not switching FlickrExport over to git just yet, but I am looking at taking one or two other small projects over to git, just to see how it will work out in practice.