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:
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.
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 site1.
3. A Trivial Custom Hook
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).
2 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).