Mercurial presentation ideas

[Giorgos Keramidas]

On Fri, 30 Apr 2010 11:13:42 -0500, Chris Sutton <bdsutton at gmail.com> wrote:
> I'm doing the second run of an introductory Mercurial talk at a code camp
> this weekend. The talk is in two main parts 1) a tutorial  of how it works -
> getting it installed and using commands 2) why it is important and how you
> can have a better workflow (as compared to Subversion/TFS).
>
> I've been working with Mercurial for about 8 months and am planning to
> switch all of my work source code to Mercurial this summer. Many of you have
> been working with Mercurial for much longer so I want to solicit more ideas
> for the talk from people on this list.
>
> So here are a couple of questions:
>
> - What were your reasons for switching to Mercurial?

  - The ability to work offline.  I am sick and tired of the long
    round-trip times of simple things like "{cvs,svn} {log,diff,update}"
    for checkouts from remote trees.

  - The ability to commit *first* merge *later*.  Merging with an
    unclean workspace is dangerous.  Having botched a few CVS branch
    merges for large (upwards of 800 MB) source checkouts, it seems
    intuitively obvious to me why committing *first* is safer and being
    able to rollback a broken merge with minimal fuss is way cool.

  - Very easy "ad hoc" team collaboration.  All it takes to work with
    another person on the same tree is "hey, here's a clone".  No huge
    lists of branching policies; no difficulties because someone has no
    authentication keys to the "golden repository"; no difference
    between a regular contributor and a new hacker who wants to fix a
    small bug; etc.

> - Why do you use prefer Mercurial to source control tools like
>   Subversion, TFS and other centralized tools?

Speed.  Quick access to the full branch history is nice.  Being able to
pull a few hundred thousand changesets in less time than it takes svn to
find out what it's about to do is also good.

Size. I've seen svn checkouts grow larger than 1 GB for full branch
checkouts in some places.  Mercurial can keep most of the history of the
same branch in less space than svn needs to keep a single checkout.

> - How does using hg improve how you work with your source?

I like using Mercurial locally to hack at an idea and see how it works.
Then when things look "mostly ok" I use a few of the extensions to
"refine" my work before it hits the main repository.  Some of the useful
extensions for my own style are:

  bookmarks
      I like keeping lots of local 'tag-like' labels that mark specific
      points in time.  As I work through the preliminary versions of a
      patch I keep adding more.  When I am done, a large number of these
      are not useful for the "main" clone.  I delete the temporary ones,
      and convert the rest to "real" tags.

  convert
      I can't even begin to describe how useful this is.  It makes my
      work with svn repos a lot more enjoyable, as I don't have to hit
      the main/remote svn repository for *all* my work.  I keep several
      local patches on top of the main FreeBSD src/ tree, converted from
      the main svn head/ branch of FreeBSD itself using a clone that I
      created with the convert extension.  I incrementally pull more
      stuff from the main svn branch and merge my own patches on top of
      that.  Without convert I'd be importing FreeBSD _snapshots_.  Now
      I have the full branch history of head/ in my local clone.

  mq
      Patch queues are very useful for my style of work.  I like making
      changes in feature-based chunks of work and pushing only full
      changesets that pass the build/test/repeat cycle a few times.
      With Mercurial Queues I can keep refining a local change until it
      really satisfies *all* the style, development and testing
      requirements I find useful.  All this is possible without hitting
      the main tree with half-done, half-tested code that breaks some
      bits ofr everybody else.  I really consider pushing well-tested
      patches a form of courtesy for my fellow-developers and MQ makes
      this not only possible but *easy*.

  rebase
      The one extension I put squarely in the "This makes MQ even more
      fun that it already is" category.  Avoiding dozens of merges every
      day, I have now grown so accustomed to rebase that I would have a
      great deal of trouble working *without* it for a long time.  This
      sort of mind-bending is a good indication in my book of things
      that are useful: if they weren't I'd be able to easily imagine how
      life was without them.

HTH,
Giorgos