Git/Mercurial vs. Subversion: Fight!
My esteemed colleague Chris Wong and I recently attended Joel Spolsky’s FogBugz 8 and Kiln World Tour event in Boston. Half the talk was a presentation of Kiln, Fog Creek’s new DVCS system built on top of Mercurial (hg). He came away from the talk with some strong opinions on what Mercurial (and its cousin git) really bring to the table. I thought I’d take a minute to discuss some of these arguments against git and hg:
Offline Version Control
Chris makes the point that switching to git or hg is an awfully big step for a single feature. Having spent five years traveling between customer sites with varying firewall configurations, network access policies, and government classification statuses, I can attest to the value of being able to work with an entire code base without relying on an internet connection. Telecommuting the past two years as a Comcast high-speed internet customer has only further rammed the point home.
Git/Mercurial is not necessarily DVCS
A lot of the remarks seem to focus on DVCS as a flawed concept, that really eventually reduces to CVCS once you actually start working with it. Indeed, on a small team, a single central repository is probably the most efficient means of sharing changes between team members. Once you start building the team out, however, the repository can be quite the bottleneck. When you want to design a larger scale workflow, you often find yourself bending over backwards to accommodate Subversion instead of Subversion accommodating you. Flexing the routes code must travel to get from one developer to another starts to become a lot more attractive. But if you still want a central repository (for example, you’re thinking of purchasing a hosted solution), both git and hg accommodate you beautifully.
Of course, there is such a thing as team branches, which brings me to my next point:
Branching and Merging in Subversion
Of course Subversion can handle branching and merging. So can CVS. And yet, the industry moved away from CVS to Subversion, citing easier branching as a reason for the switch. Branching pain is one of the most important cost differentiators in software development shops. It is at the very least worth a look.
Subversion merging improved substantially with the addition of a metadata tag called mergeinfo, which tracks revision numbers that have been merged into a given branch. This is a patch over an old problem of Subversion, to attempt to prevent SVN from merging the same changeset twice. Chris points out that git-svn (in its current version) does not correctly update this property during a merge. Valid point. But if one thinks of git-svn, not as a different version control system, but as a Subversion client, then his example serves to prove that there is inconsistent client support in the wild for svn:mergeinfo. On a large team, with developers using the best tools that make them the most productive, this property quickly becomes unreliable. Essentially, Chris’s argument reduces to, “As long as everyone just uses Subversion 1.6, Eclipse, and Tortoise SVN on Windows, we’ll all be fine!”
DVCS as a superset of VCS
Chris complains that by creating a superset of essential functionality, DVCS systems introduce complexity to a developer’s workflow, and creates more opportunities to make mistakes. Out of all his arguments, this is probably the one I have the most intuitive sympathy for. However, if one wants to do feature branching, it turns out the number of steps to feature branch in Subversion and git/hg are the same. I wrote up a technique in a prior post. The only thing git and hg make more difficult is the “cowboy” (commit to the head and forget) and “go dark” (go offline for months and then try to resync at the end) styles of development. That sounds more like a feature to me than a bug.
I’ll admit to my ignorance of Subversion’s roadmap. Looks like they’re hard at work implementing a lot of features that come standard with git and hg. You should keep in mind, though, that git and hg are not standing still either. They’re not just working to stay ahead of SVN; they’re also competing with each other, and the untold number of competing DVCS’s out there.
Hashes vs. Revision Numbers
Yes, integers are easier on the eyes than hashes. But when working with git or hg, you almost never refer to individual revisions themselves. Almost every changeset refers to a branch, which you name yourself. You can also tag till your heart’s content. Practically the only use cases for working with individual revisions in git or hg are reverts and cherry picks. I ask you Chris, which would you rather call a changeset, r4817:4907, or bug_383?
Subversion is a terrific product, one I found myself in the role of championing for many years. Anyone “bashing” Subversion should be sentenced to 2 years working on a ClearCase project, which will make them appreciate just how much Subversion has done to advance the state of the art. But Subversion is no longer the state of the art, git and hg are.