Git-y-up - chasing the version control flame at a leasurely pace

What Distributed Version Control System (DVCS) did you wake up with this morning? (And what were you thinking/drinking last night that put you in this awkward position?)

We've been moving all of our new development at work from CVS to Subversion (SVN) over the past year, following an industry trend in that direction. Mainly because CVS wasn't built from the ground up to be distributed and because we change/add source directory structures more than occasionally (new Java package, for instance). CVS doesn't deal with those directory structure changes easily, at least not outside of straight-up additions/deletions, because it only versions files (not always a bad thing, as I'll get into later). If you're somewhat-obscure-movie minded, you can think of it like the geographic difference between Elm and Main Street in Pleasantville - Elm is like CVS - it's shorter and only has houses.

And I'll stop-hyphenating-everything-to-make-up-words-now.

Of course we're following behind that CVS to Subversion industry trend by several years and are about to get lapped on the track as a good chunk of the open source community are filing for SVN divorce, largely falling into the arms of Git, though others have flown the coop with Mercurial and Bazaar.

Branching and Merging woes are the usual causes cited for this move away from Subversion and I understand why. Sure, SVN allows you to branch pretty much anything (because branches are literally just copies of your whole enchilada). It's the merging that kills ya. It's better than CVS in that you actually can branch and merge directory structures. And it's gotten easier with SVN 1.5 and 1.6 but the dreaded merge can still be very painful and time consuming endeavor.

Where Subversion takes a step back from CVSland, in my opinion, is in the way it represents the versioned data: an opaque-to-you-cause-its-binary database. Sorry, a break out of hyphenitis again. With CVS, your file is still a file (granted, it's all versions of your file with a bunch of metadata, but you can hand fix it if something goes wrong). If the SVN repo gets corrupt in any way, well - hopefully your backup is recent and you only lose a few hours.

Git doesn't have the Subversion/CVS concept of checking files and modules out from a repository. With Git you clone the master repository and from that point on, the module you're working on is also a full fledged Git repo (you can commit to it, you can branch and merge your files to your heart's content). I'm not here to sing the praises of Git - I don't know enough about it yet. And others are doing a fine job of tooting git's horn. I think more than git itself, the thing that gets the OSS community excited is the GitHub, a source code hosting / collaboration / cloudy kind of thing. SCM served up SAAS-style.

I know even less about Mircurial and Bazaar than I do Git. And of course there are a number of popular commercial products (Perforce, ClearCase, PVCS, etc.). Some better than others, all have their own special fleas. As that giant of philosophy, Gordon Gekko, once said, 'Pick the dogs with the least fleas.' There you go. Of course, one person's fleas are another person's flea circus. 'Buddy's learning.'

So we'll keep an eye on the exodus even as we continue to mush onward with Subversion. I hope the Subversion maintainers are taking some cues from these other DVCS offering as they plan and prioritize upcoming releases. Perhaps by the time folks start migrating off one of these "newbies", there will be room for us to climb aboard.