It seems that the indie Mac developer community has spoken, and subversion is the current version (or is it “revision”) control system of choice for the present. Now, it’s important not to blindly accept the indie Mac developer community’s word on such matters, or you may find yourself exclusively developing using Ruby on Rails using TextMate, but I’ve begun wondering if my “love at first sight” reaction to git was actually justified based on the fact that after setting myself up using git on several projects, I (a) couldn’t figure out how to get remote push (or whatever it’s called) working, (b) didn’t want to have to pay for a solution (for large and/or closed source projects), and consequently (c) found myself not using git after a while (going back to my good old “dated archives of giant folders full of files” system of version control).
I’d looked at subversion before, but not really hard enough to really grok it, and at the time I was forced to use perforce by my (then) employer. It had become increasingly annoying to me that subversion was being seamlessly supported by all kinds of tools I used (e.g. Coda) while git pointedly wasn’t. Now there are two excellent graphical clients for subversion — Versions and Cornerstone — as well as integrated support of varying levels of usefulness in Coda, Textmate, XCode, et al. For git there’s GitX — which has the advantage of being free, and the disadvantage of being nowhere near as nice.
There are two other really important differences between git and subversion (that I can see), one of which — I think — plays in git’s favor, while the other can play in either’s favor (but for me it’s subversion’s).
Files Are Not Atomic in git
The first key difference is that git isn’t fundamentally file-centric, or at least that’s the idea. The core elements are branches, revisions, and blobs of code — the signal event being that if you move a function from file A to file B, or rename file A to B there’s a good chance git will recognize these events for what they are automagically. Other systems, such as subversion, will treat the first event as “something disappeared from A, and something appeared in B”, and similarly the second event as “file A was deleted, and file B was created”. If this were git’s only difference from subversion then git would win and subversion would lose, at least for me.
There Is No Central Repository in git
The second key difference in git is that it’s very democratic. In essence, every user’s repository is “the master” and can merge in other people’s changes, or not (assuming it can find them).  Indeed, a core idea of git is that branching (both creating and merging) branches should be “cheap” and thus it should be normal to expect lots of branches lying around. While this seems like a Good Thing from an idealistic point of view, it doesn’t seem to me to match my idea of what a “project” is, and it’s probably why I’ve never used git as it appears to have been intended. Maybe in my heart, I’m just not that wild and crazy.
If we are to infer from git’s strengths what Linus Torvalds expected a project to look like, it’s a bunch of independent developers each with their own unique multi-branched copy of a codebase, exchanging their different takes of the project at arbitrary intervals and then folding or not folding other developers’ various changes into their own branches, and occasionally assembling some kind of coherent “release” version (and presumably closing off and setting aside huge numbers of branches and starting over — to preserve their own sanity if nothing else).
Other Differences
There are other differences between git and subversion that all tend to play in git’s favor:
- git produces fewer files and smaller repositories
- git produces a single .git folder for an entire project (instead of scattering .svn folders into every single subfolder the way subversion does)
Neither of these matter much to me since my projects tend to be fairly small, but if I were working on a larger or more complex project the additional complexity of getting git working on my server would probably be justified. Of course I wouldn’t be surprised if subversion switches to a single folder model at some point, making all our lives easier.
Finally, there’s the question of licensing. Subversion is has a liberal BSD/MIT-style license which means that many subversion clients have subversion built in requiring no additional installation. Because git is GPL licensed shareware vendors can’t wrap a closed source program around it, and so you tend to need to install a git client separately from git itself, and then figure out how to get them to talk to each other. (I don’t know why a git client can’t simply do the install for you though, so this is more likely just a sign of git’s relative novelty.)
Mercurial
Mercurial (it’s hg from the command line — yay a chemistry reference!) is in many ways very similar to git but — as some have put it — more Mac-like. (It’s also written in Python, whereas git is cobbled together out of a bunch of different things — notably C and Perl.) Everything I’ve said about git versus subversion* pretty much applies to Mercurial vs. subversion (complete with the lack of good graphical front ends for Mac OS X and the licensing issues).
Edit: here’s an interesting talk about Mercurial and I stand corrected — it’s 95% Python and 5% C. Of course this means Mercurial vs. git comes down to Python versus Perl — no contest for me!
Another edit: one thing Mercurial has going for it is bitbucket.org, which works beautifully and is (apparently) totally free (for now at least). One nice thing about distributed systems is that there’s much less in the way of “stickiness” since everyone has the whole history. Based on my brief experience with Mercurial I’m starting to strongly favor it over git and subversion — maybe enough to use it from the command line and possibly even enough to write a nice front end for it.
* It’s kind of sad that the subversion folks haven’t run with the whole “subversion” theme in their naming conventions. So much potential wasted!
All Decisions Are Provisional
My take on it is that git (/mercurial) is the new hotness, which means we’ll see an explosion of git (/mercurial) front ends over the next couple of years. In the mean time, I’m happy to use subversion and migrate when there’s something as good as Cornerstone for git (/mercural) (or — better yet — Cornerstone adds git (/mercurial) support).