initial commit, including theme

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>
+