The Flow Of Mercurial

As you may have noticed, I moved the entire site contents to Mercurial a month or so ago, and since then I’ve also adopted it as my main SCM, using it not only for Yaki development but also to keep track of changes to my Scripts folder, assorted machine configuration files, etc.

And I’m loving it. I can sit at any machine, start typing away, commit stuff as I go along, and then push stuff back to this site when I’m happy with it – Mercurial has so far been very forgiving when it comes to merging multiple changesets from several machines (often with somewhat out-of-sync local copies of the content).

In terms of scale, it’s been working fine with the 11000 static files that comprise this site’s raw markup and media (plus the assorted 3K that the local Yaki instance consists of), so I daresay it can handle the workload just fine.

Three things that I’ve found absolutely invaluable along the way were:

1. MacPorts

Being able to just do sudo port install mercurial and enjoying painless setup is, as usual, the best possible testament to the BSD way of doing things.

I’ve also been able to set up Mercurial by hand on a few oddball systems (including my NSLU2 and Cygwin), but if you’re using a Mac, MacPorts is what I’d recommend right now.

2. TextMate

TextMate by itself is, of course, plenty good enough for anything coding-related.

But being able to type mate ~/space/foo/index.txt (or dragging the entire folder and pecking through the file tree) makes it tremendously easy to manage this site¹.

So I can start editing a file and preview it there using the Textile bundle² (Ctrl-Alt-Cmd-P). Then, when I’m happy with my changes, I use the Mercurial bundle to commit them (Ctrl-Shift-M, 5).

3. A Trivial Custom Hook

But that in itself isn’t all that new – I was already doing mostly the same and editing stuff directly via MacFusion.

The icing on the cake, however, is being able to use the Mercurial bundle’s “push to default repo” command and have all my changes published instantly – all via the SCM, and straight from TextMate.

Since my local clones all have the default repository set as the servers’ (which they access over an SSH URL), hg push already did nearly the right thing – but the changes were not mirrored on the site’s local copy – they were only stored inside the SCM.

To do that, all I needed to do was add a little magic to the server site of things – i.e., adding a changegroup hook to the server repository:

$ cat space/.hg/hgrc 
[hooks]
changegroup = hg update

This ensures that whenever I push a number of changesets over, the “live” clone is updated automatically, leaving it to Yaki to re-index and re-render content as appropriate. And all I need to publish content is hit Ctrl-Shift-M and type “push” – TextMate and Mercurial do the rest behind the scenes.

I’ve also started maintaining a Yaki-based shared wiki with a few people, and this approach seems to be working OK (we have different tastes in markup formats and different rhythms for editing, and the Yaki – Mercurial combination seems to be able to cope).

—

¹ Of course, one of the great things about Yaki is that everything’s a plaintext file – no messing about with weird formats, blogging APIs or databases…

² Or Markdown, or HTML – right now this site is roughly 95% raw HTML since I migrated from PHPwiki, and as I go along I refactor it into Textile (mostly, since I find it more readable) or Markdown (using Piper or HumaneText on my older machines, and ThisService on my MacBook