version-control – David Lynch

I just watched Linus Torvalds talking about git, the distributed version control system he wrote.

What struck me here is that several times in this talk he was asked by Google employees variations on the theme of “why should we use git?”, and he didn’t have a compelling answer. His statements boiled down to “we have an alternative way of visualizing branches, and subtly different workflows”.

Many of his “git is awesome” points were rooted in specific objections to CVS. In particular, the complaints about branching and merging, and finding changes to a particular subset of a repository. I’m not saying git isn’t good at these things, I just think he should be comparing to SVN, which enables less cheap shots.

None of this is to imply that I don’t like git. I’ve been playing with it recently, and it seems impressive. I can’t say that its distributed nature feels very essential to me – but then, I’m not a member of a massive pseudo-anarchistic project like the Linux kernel. I suspect that until you hit some critical mass of independent developers on a project, git and SVN are fundamentally interchangeable.

The things that have actually made me go “ooh” about git thus far are offline commits, and content-tracking across files.

I’d like to take a moment to (a) completely alienate my audience, and (b) ruin my credibility. I will do this by discussing the semantics of a particular operation of the Subversion version control system, and explaining how poorly I initially understood it.

It took me a while to realize how svn merge should be used. My intuitive sense of the usage of the command diverged significantly from its actual use.

When I think of it as “merge” the syntax that intuitively appears is svn merge [source] [target], with the intent of merging “source” into “target”.

This led to my attempting to merge from branch HEAD to trunk HEAD, and be puzzled at the lack of effect.

I find that everything fits together if I think of svn merge as a synonym for svn repeat. You’re asking for the changes between two revisions to be applied to the current working copy.

Thus svn merge branches/coolfeature trunk doesn’t do anything because it doesn’t describe any changes.

What’s required is svn merge branches/coolfeature@73 branches/coolfeature@HEAD, which takes the changes made to the coolfeature branch between revision 73 and the latest revision, and applies them to the working copy you’re currently in.

(It’s much shorter to write this as: svn merge -r 73:HEAD branches/coolfeature)

The awkward bit is finding out when you should start merging from (the “73” in my example). To do this you have to read the logs and find either the revision where you created the branch or the last revision you merged from, whichever is more recent.

All this should become irrelevant shortly, though. Subversion 1.5 (according to an aside in this developer blog post) will automatically track much merge metadata so the requirement to specify revision ranges of changes to merge should be eliminated in the common case. I look forward to it.