path: root/content/posts/2007-04-04-mercurial-upgrade.html

---
date: "2007-04-04T23:07:36Z"
title: Mercurial Upgrade
---

<p>Say hello to <a href="http://selenic.com/mercurial/" title="Mercurial distributed SCM.">Mercurial</a>, my long-overdue replacement for <a href="http://nongnu.org/cvs/" title="Crappy Version Control^W^W^WConcurrent Versioning System.">CVS</a>.
Unlike <a href="http://nongnu.org/cvs/" title="Crappy Version Control^W^W^WConcurrent Versioning System.">CVS</a> and <a href="http://subversion.tigris.org/">Subversion</a>, Mercurial is a <em>distributed version
control system</em> (<acronym title='Version Control System'>VCS</acronym>), which means (among other things) it doesn't
have a central repository, has disconnected (non-networked)
commits, and allows you to group small changes together as "change sets". 
Other well-known distributed <acronym title='Version Control System'>VCS</acronym>s include <a href="http://bitkeeper.com/">Bitkeeper</a>, <a href="http://kernel.org/pub/software/scm/git/docs/">Git</a>,
<a href="http://abridgegame.org/darcs/">Darcs</a>, and
<a href="http://venge.net/monotone/">Monotone</a> (there are <a href="http://better-scm.berlios.de/" title="Comparison of several version control systems.">more</a>).  While searching for a <acronym title='Concurrent Versioning System'>CVS</acronym>
replacement, I spent some time using Subversion, Monotone, and Git;
here's a brief overview of my experience with each one.</p>

<ul>
<li><p><a href="http://subversion.tigris.org/">Subversion</a>: Subversion is probably the most popular <acronym title='Version Control System'>VCS</acronym>, so 
you're probably already familiar with it.  I'll dispense with the
pleasantries and skip straight to the problems.</p>

<p>For the past several months I've been using a private, home Subversion
repository for small projects, snippets of code, configuration
files, scripts, and various other knick-knacks.  Along the way, I
noticed several things about Subversion that bother me.  For example,
until version 1.4, common operations like <code>svn status</code> and <code>svn
commit</code> were uncomfortably slow under Subversion.  They're better now,
but still not as fast as I'd like.  Copying and moving large groups of
files is still painfully slow (moving several hundred megabytes of
files took me well over 20 minutes).  </p>

<p>Branching in Subversion is primitive (and slow, since it's really just
a copy).  For me this is a major problem, because in addition to
revisions, I also want to use branches for quick, version controlled
staging areas for new features.  That's a problem in Subversion,
because branches are expensive, and merging is kind of wimpy.  </p>

<p>It's a genuine hassle to require network access for commits; I
regularly work remotely, and even though I have <acronym title='Virtual Private Network'>VPN</acronym> access (courtesy
of <a href="http://openvpn.net/">OpenVPN</a>) it's still kind of distracting to wait for common
commands like <code>commit</code>, <code>add</code>, and <code>copy</code> .  My alternatives? Move the
repository to a public server with better bandwidth (which makes it
slower for me to access while I'm at home, plus it's not really
private any more and I'm <em>still</em> dependent on network connection) or
hold off on commits until I'm at home (which is contrary to committing
in small, incremental changes, my preferred modus operandi).</p>

<p>Finally, and most importantly, Subversion is centralized.  Why?  It
imposes all sorts of workflow restrictions that haven't been 
necessary since VHS tapes went out of style.  For example, I have
roughly five gadzillion projects in various states of brokenness and
disarray that I'm just not ready to publish.  Distributed version
control systems have no central repository except one that is
designated by convention, so I can commit locally, push to my private
repository when it's convenient, and publish to the public repository
when I'm damn good and ready.  Subversion can't do any of this without
cheating, of course, so I'm forced to either migrate projects to the
public repository without their history or use <code>svndumpfilter</code>
chicanery to bludgeon Subversion into doing something it should be
able to do out of the box.  Which sounds an awful lot like trying to
copy and move files in <acronym title='Concurrent Versioning System'>CVS</acronym>. Which is why we were supposed to upgrade
to Subversion in the first place.  Oops...</p>

<p>(Subversion isn't all bad, by the way.  It's certainly a huge
improvement over <acronym title='Concurrent Versioning System'>CVS</acronym>.  It integrates well with <a href="http://rubyonrails.com/" title="The Ruby on Rails MVC web framework.">Rails</a>,
<a href="http://eclipse.org/">Eclipse</a>, and all the other fancy toys kids use these days.
Plus Subversion has all sorts of nifty extensions like <a href="http://tortoisesvn.tigris.org/" title="Integrate Subversion with Windows explorer.">TortoiseSVN</a>
and <a href="http://trac.edgewall.org/">Trac</a>.  I use Subversion daily at work.  I just need things
Subversion doesn't support by design).</p>

<p>I'd be derelect in my blog posting responsibilities if I didn't
mention <a href="http://svk.bestpractical.com/view/HomePage">SVK</a>, a distributed <acronym title='Version Control System'>VCS</acronym> built on Subversion that supports
repository mirroring and disconnected operation.  I can't say much
about SVK because I don't have much experience with it, although I'm
fairly sure SVK has neither the speed nor the power of Mercurial and
Git.  Personally, I don't really see the point of keeping Subversion
around for the sake of keeping Subversion around, particularly in lieu
of <a href="http://www.cs.bris.ac.uk/~henkm/svn.html">Subversion's marvelously atrocious track record with repository
corruption</a>.</p></li>
<li><p><a href="http://venge.net/monotone/">Monotone</a>: I wanted to like Monotone.  I stumbled across a
reference to it in the <a href="http://sqlite.org/" title="Embedded relational database.">SQLite</a> documentation, and spent several
months putting up with Monotone's warts after <a href="http://kerneltrap.org/node/4968" title="Linus Torvald plugs Monotone on the Linux Kernel Mailing List.">Linus plugged it on the
<a href='http://kernel.org/'>LKML</a></a>.  I like the extensive documentation, simple
command-line interface, <a href="http://lua.org/">Lua</a> hooks, proper Windows support.
Internally, Monotone makes extensive use of strong cryptographic
primitives, which I wholeheartedly support.  </p>

<p>Unfortunately, Monotone is slow.  Dog slow. An initial repository pull
(checkout, in <acronym title='Concurrent Versioning System'>CVS</acronym> parlance) is so slow that a many Monotone
users provide a publicly downloadable snapshot of the initial pull
instead.  The last time I used Monotone, the crypto certs were their
own special blend; I'd prefer either <a href="http://ietf.org/html.charters/openpgp-charter.html">OpenPGP</a> or <a href="http://en.wikipedia.org/wiki/X.509">X.509</a>.</p>

<p>(Oddly enough, my first look at Mercurial was right after I started
testing Monotone.  I wasn't initially interested in Mercurial because
I was still stuck on Monotone.  I didn't feel like Mercurial offered
much more than Monotone, and I hadn't fully appreciated the speed
difference between the two).</p></li>
<li><p><a href="http://kernel.org/pub/software/scm/git/docs/">Git</a>: Git was (is) right at the top of the list.  It's fast,
possibly (probably?) even faster than Mercurial.  It has features
Mercurial doesn't support (<a href="http://kernel.org/pub/software/scm/git/docs/git-rebase.html">rebase</a>, for example, although I believe that can
be clumsily emulated with <code>bundle</code> and <code>unbundle</code>).  <a href="http://keithp.com/">Keith Packard</a>
wrote a post titled <a href="http://keithp.com/blog/Repository_Formats_Matter.html">"Repository Formats Matter"</a>,
advocating Git for X.org.  His post briefly mentions Mercurial and in
a positive light, but dismisses it prematurely for what I think is a
completely asinine reason; old, obscure <code>ftruncate()</code> bugs in the 
<a href="http://kernel.org/">Linux kernel</a> (see <a href="http://selenic.com/pipermail/mercurial/2006-November/011678.html">this post</a> on the Mercurial
mailing list for a more thorough rebuttal of Keith Packard's
<code>ftruncate()</code> sillyness).</p>

<p>I only have two real gripes with Git: the Windows support sucks (it
half-works via <a href="http://cygwin.com/">cygwin</a>, which doesn't really count), and the
command-line interface makes me feel stupid.  </p>

<p>The second one is the deal-breaker for me.  While I may not be
Mensa material, I've spent enough time using version control that I
feel like I should be able get at least the <em>gist</em> of a new VCS in a
couple of minutes, be comfortable with it within a day or so, and
proficienct with it within about a week.</p>

<p>I don't really think that's unreasonable.  Even if it is, so what? A
VCS is a tool, one that's supposed to make <em>my</em> life easier.  If I
can't use it without consulting the documentation every couple of
minutes then it's just getting in my way.  </p>

<p>I simply refuse to waste my time learning the nuances of an interface
that is complex for no other reason than the programmer couldn't see
far enough past their own idiosyncratic whims to long enough provide
an interface without the learning curve of a black diamond ski slope.
This is particularly true for an application like Git that has few,
if any, tangible benefits when compared to it's more intuitive
counterparts.</p></li>
</ul>

<p>The silver lining here is that I eventually stumbled on Mercurial.  And
by stumbled, I mean <a href="http://richlowe.net/">Richard (richlowe)</a> told me about it
(just like he told me about <a href="http://vim.org/">Vim</a>, <a href="http://gnu.org/software/screen/">Screen</a>, <a href="http://mutt.org/">Mutt</a>, <a href="http://ruby-lang.org/">Ruby</a>, and
a whole
lot of other cool stuff I use regularly).  He knows a lot more about
version control software than I do, but I didn't really pay any
attention.  At least not until I noticed that Mercurial seemed to be the
<em>only</em> free VCS that wasn't enclosed in a long and colorful string of
profanity when he talked about it.</p>

<p>Anyway, the more I use Mercurial, the more I like it.  It meets all of
the requirements I mentioned above, plus it has the speed and power of
Git and the simplicity of Subversion and <acronym title='Concurrent Versioning System'>CVS</acronym>.  Mercurial is actively
developed, has full Windows support, and it includes extensions that add
support for <acronym title='Pretty Good Privacy'>PGP</acronym>-signed tags and <a href="http://selenic.com/mercurial/wiki/index.cgi/MqExtension">Quilt-style patch queues</a>.</p>

<p>The real killer feature for me, though, is that everything I try just
works.  Setting up read-only, web-accessible public repository only took
a minute or two of reading, and making an entire directory of Mercurial
repositories available only took a couple more minutes.  I had
comparable experiences with branching, tagging, signing tags, and
pushing changes to multiple repositories.</p>

<p>The only warts I've found in Mercurial so far are minor; the web
interface needs a bit of cleanup, and there should be a straightforward
way of adding repository defaults like style, contact and archive
formats via the top-level <code>htwebdir</code> configuration file.  The native
import features are still a bit lacking, although you can use <a href="http://darcs.net/DarcsWiki/Tailor">Tailor</a>
to convert data from all but the most esoteric or convoluted
repositories.</p>

<p>That's about all the advocacy I can muster up at the moment.  If you're
interested in reading more about the state of distributed version
control systems, there are more detailed VCS comparisons <a href="http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html">here</a> and
<a href="http://better-scm.berlios.de/" title="Comparison of several version control systems.">here</a>.</p>

<p><strong>Note:</strong>  I've had this post sitting in my queue for months.  I
just brushed off the cobwebs, cleaned up the typos, and posted it.
In that time Mercurial has picked up a bit of publicity, and development
has been moving along at a steady clip.  I tried to remove the bits that
no longer apply, but let me know if I missed anything.</p>

<p><strong>Edit:</strong> This article was linked on <a
href='http://reddit.com/'>Reddit</a>; some additional conversation (and
my responses) can be found in <a
href='http://programming.reddit.com/info/1iib6/comments'>the comment
thread</a>.
</p>