Resources for learning Mercurial?

[ewemoa]

After watching Linus' talk on git (thank you Mark0, tinjaw) and talking with mouser, Mercurial seemed worth looking into, so...

Checked the forums here for previous mentions and below is a brief summary of some results:

  houstier referenced:
    Understanding Mercurial (redirects) via this post

  fenixproductions referenced:
    Mercurial Wiki  (redirects) via this post
    A tutorial on using Mercurial (redirects) via this post

  tomos referenced:
    A book on Mercurial - pdf (not found -- try Google w/ hgbook.pdf), online (redirects) via this post
    ----
    Editorial remark: Seems like the book in question used to be titled:

      Distributed revision control with Mercurial

    now it seems to be called:

      Mercurial: The Definitive Guide

  mouser referenced:
    Use Mercurial, You Git! (not found) via this post
    ----
    Editorial remark: Didn't succeed in locating a cached version of the article in question anywhere, but found the following:

      http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git

    IIUC, one of the comments is from the author of the aforementioned article.

If any Mercurial users have things to add, please pitch in

[TheQwerty]

Use Mercurial, You Git from Google's cache.

But in case that is down as well...

<h2>Tuesday, February 5, 2008</h2>
<h3><b>Use Mercurial, you Git</b>!</h3>

It's a land rush of revision control, I tell ya!  Among the <a href="http://en.wikipedia....rsion_Control_System">stable of eager candidates</a> for best-loved DVCS, <a href="http://git.or.cz">Git</a> and <a href="http://www.selenic.com/mercurial">Mercurial</a> seem to be the two tools capturing the most programmer heart-share for now.<br /><br />Git is admired because Linus Torvalds wrote it, but Mercurial is <em>better</em> because he didn't.<br /><br />Developers with refined sensibilities are in a tough spot right now.  We'd clearly like <em>something</em> to take the place of centralized tools like Subversion.  But why, oh why, does it have to be Git?  Let's examine the hype and the reality:<br /><h4><cite>"<a href="http://mjtsai.com/bl...5/subversion-to-git/">The user interface is... not too bad</a>"</cite></h4><br /><em>False.</em>  I've heard dozens of authors whining about Git's usability.  I thought maybe they were overstating the case, or were just confused.  Then I tried Git.  If anything, they were being too kind.  Git polluted my /usr/bin with nearly <em>150</em> distinct binaries.  Mercurial has <em>one</em>.<br /><br />And if you think that you only need one or two of those commands for daily use, you're an optimist.  Check out the <a href="http://rubinius.ligh...jects/5089/using-git">"easy use" guide</a> from, by the way, an awesome Ruby project.  You're expected to juggle, depending on how you count them, about ten commands, just for day-to-day work.<br /><br /><blockquote>The <code>git rebase</code> command will save your changes away, update the topic branch, and then reapply them.... Warning! If you are sharing a branch, you must use: <code>git merge master</code>...  Rebase causes the commit layout to change and will confuse anyone you've shared this branch with.</blockquote><br /><br />Huh?  <a href="http://static.flickr...03564_7281ad0588.jpg">Blah blah blah Ginger blah blah</a>.  For day-to-day use of Mercurial, you only need <code>hg fetch</code> to get code, and <code>hg commit</code> to give code.<br /><br />Git apologists will tell you that you need all these extra commands because Git was written with the "UNIX philosophy" of small tools that do only one thing, and do it really well.  Which brings us to our next myth.<br /><h4><cite>"<a href="http://git.or.cz/">Git... consists of many commands that do one thing well</a>"</cite></h4><br />O RLY?  From <a href="http://lwn.net/Articles/210045/">Git's own gurus</a>:<br /><br /><blockquote>Git checkout can do three separate things:<br /><ol><li>Change to a new head.</li><li>Revert changes to a small number of files.</li><li>Create a branch.</li></ol></blockquote><br />Those are pretty massively different tasks.  So much for "doing one thing."  I'll leave it as an exercise to the reader to debunk the "well" part.  Hint: try using git for any non-trivial project.<br /><br />Having lost the simplicity argument, Git-folk will try to tell you that the reason they dumped 150 pieces on your floor was so that you can build your own revision control software:<br /><h4><cite>"<a href="http://lwn.net/Articles/131312/">It's not an SCM.... I bet you could make a reasonable SCM on top of it, though</a>"</cite></h4><br />That was from Linus himself in the early days, though Git's recent admirers echo the same sentiment: <cite>"<a href="http://utsl.gen.nz/t...n/intro.html#wtf-why"><code>git</code> is first and foremost a toolkit for writing VCS systems</a>."</cite><br /><br />Who cares?  I ordered a version control system, not a toolkit for building one!  If I'd wanted building blocks for rolling my own, I'd have gone to Home Depot and bought a 1 and a 0.  You can build any software you like out of those, including a source control tool.<br /><br />Mercurial is a <em>working</em> DVCS right out of the box.  Why not use it?<br /><h4><cite>"<a href="http://wincent.com/a.../one_of_the_thin.php">The model is rock solid and infallible because it is simple.</a>"</cite></h4><br /><em>Horseshit.</em>  I've even unwittingly <a href="http://rubyforge.org...November/004583.html">repeated</a> this stinker myself.  Let's break it down a little.  <a href="http://utsl.gen.nz/t...ntro.html#yay-simple">Quoth</a> the explainers (alongside a rat's nest of UML, to boot):<br /><br /><blockquote>The core Git filesystem can be explained as four types of objects: Blobs (files), Trees (directories), Commits and Tags.</blockquote><br /><br />Unfortunately, no, it can't.  The core of Git may well be <em>implemented</em> as four kinds of things.  But to get even the most basic tasks done, you need to know repositories, working trees, branches, remotes, masters, origins, index caches, and a bunch of other unexplained concepts.<br /><br />The manual pages are no help, for the same reason that "look it up" is no help to someone with a spelling question.  You have to know the name of the command before you can look it up.  And the commands are so obliquely named that there's no way to reason upward from what you know about the alleged "four kinds of objects" to make an educated guess as to which of the 150 commands you're supposed to use.<br /><h4><cite>"<a href="http://code.google.com/p/msysgit/">Git on Windows is only officially supported using Cygwin</a>"</cite></h4><br />This is another way of saying, "Git is not supported on Windows."<br /><br />I <em>like</em> Cygwin -- it's one of the few things that raises my (mandatory) Windows experience at work from "completely unbearable" to merely "excruciating."  But forcing my teammates to download and wrestle with the Cygwin setup, much less learn Bash, makes Git a complete non-starter in the one place where it could do me some good.<br /><br />Punting to Cygwin, in this day and age of awesome scripting languages (like <a href="http://www.python.org">the one Mercurial is based on</a>) is basically shouting to the world, "I can't be bothered to do my job properly."<br /><br />Actually, speaking of scripting, using Python is <em>exactly</em> why Mercurial can be so scriptable and extensible without dumping 150 inscrutable binaries into your /usr/bin.<br /><h4><cite>"<a href="http://kubasik.net/blog/2007/01/04/19/">git is reliable</a>"</cite></h4><br />I wanted to believe this.  Really, really wanted to believe it.  Unfortunately, Git fails at the most fundamental of source control tasks -- so much so that I'm going to have to take that up in a different post.<br /><br />The short version is that Git encourages and even requires you to tamper with your project's source history, and that is a recipe for disaster, not reliability.<br /><br />In summary: Git was created by a brilliant mind and is maintained by a posse of smart, motivated developers.  But it's a stinker.  Its power might justify the agonizing experience of using it, if there weren't any better alternatives.  There are.<br /><br />Code in good taste.  Use Mercurial.<br /><br /><strong>UPDATE</strong> <em>2008-2-6, 9 PM</em>.  In retrospect, a discussion on reliability should just be about data integrity: having a repository that's resistant to crashes and hardware failures and such.  The concerns in the final section -- discovering how to get data reliably out -- are not a pronouncement on the resilience of the repository format.  They have to deal with usability and coherence.  "Reliability" as a fuzzy human term is too broad a word here.

Posted by undees at 9:55 PM

Edit: Changed quote to the source of the article, so links are included.

[mouser]

nice find qwerty 

[ewemoa]

Thanks for your detective, restoration, and preservation-for-posterity efforts, TheQwerty

[housetier]

I just stumbled across Hg Init: a Mercurial Tutorial. It looks very fresh and modern.

[ewemoa]

Thanks for sharing this

Hmm, nice images -- Balsamiq may be?

[f0dder]

Thanks for sharing this

Hmm, nice images -- Balsamiq may be?

-ewemoa (February 27, 2010, 08:17 PM)

Yeah, that's what I was thinking.

Dunno what to think of the guide, though... I think I'm growing too old for the kind of forced and completely irrelevant attempt at humor that Spolsky is using. It's not that I want tech stuff to be entirely dry and to-the-fact, but I'd like some relevance in the humor... and there was none of that in Hg Init, just silliness.

[ewemoa]

Perhaps for bit-by-bit learning the following will come in handy:

  http://hgtip.com/

[Deozaan]

Thought I'd pop in here and mention that though this isn't really useful for learning Hg, http://bitbucket.org/ is a good site for hosting an online Hg repo.

With a free account you can create one private repo and unlimited public repos, up to 1 GB (total) in space. BitBucket also provides a wiki (which is actually an Hg repo itself!) and issue tracker for each project, so it's a pretty good project management system.