diff options
Diffstat (limited to 'content/posts/2007-04-04-mercurial-upgrade.html')
| -rw-r--r-- | content/posts/2007-04-04-mercurial-upgrade.html | 183 |
1 files changed, 183 insertions, 0 deletions
diff --git a/content/posts/2007-04-04-mercurial-upgrade.html b/content/posts/2007-04-04-mercurial-upgrade.html new file mode 100644 index 0000000..feaee46 --- /dev/null +++ b/content/posts/2007-04-04-mercurial-upgrade.html @@ -0,0 +1,183 @@ +--- +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> + |