Powered by the Pete

From the ill-informed, to the ill-informed

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.

Subversion Roadmap

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 Bashing

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.


October 29, 2010 - Posted by | Uncategorized

1 Comment »

  1. ClearCase. ouch.

    How can I leave a comment about subversion with the risk of that kind of penalty?

    Comment by unscriptable | November 2, 2010 | Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: