The Flow Of Mercurial

As you may have noticed, I moved the entire site contents to , and since then I’ve also adopted it as my main SCM, using it not only for 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 – 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 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 by hand on a few oddball systems (including my and Cygwin), but if you’re using a , MacPorts is what I’d recommend right now.

2.

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 site1.

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

3. A Trivial Custom Hook

But that in itself isn’t all that new – I was and editing stuff directly via .

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

Since my local clones all have the default repository set as the servers’ (which they access over an 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 to re-index and re-render content as appropriate. And all I need to publish content is hit Ctrl-Shift-M and type “push” – and do the rest behind the scenes.

I’ve also started maintaining a 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 combination seems to be able to cope).

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

2 Or , 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 (mostly, since I find it more readable) or (using or HumaneText on my older machines, and on my MacBook