I am afraid that I have to admit that the development of this site has until now proceeded in what any programmer must consider a state of sin: it was not under version control. Sure, I had periodic snapshot backups, but forget about versions, branches, and reverts.
The reason for this is that I was under the mistaken impression that my VCS of choice, git, made it difficult to set up remote branches. I think my confusion stemmed from the fact that it is somewhat tricky to set up public-facing ones with good commit-access control etc (which is why GitHub is so great).
Now that I looked into it more, I find it's actually tremendously easy, and
I've got a really great work-flow set up: I have a master repo on the server,
a development repo on my laptop, and another one in the directory from which
the site is served. I can make changes on my laptop (and thanks to the magic
of makefiles and m4 macros, keep a separate dev config file), and then push
those to the master repository. When I'm ready to launch, I just pull them to
the serving repo and run a make prod.
Setting all this up was surprisingly easy. The first step is to set up the
master repo, using git --bare init. This initializes an empty
repository, additionally specifying (via --bare) that git need
not bother with anything but the repository metadata itself, and can ignore
the actual working files. The two client repositories can then either be
cloned from this master one, or if one of them already contains data, simply
add the master as a remote branch. Pushing and pulling from one repo to
another is now a breeze.
As a result of this exciting development, I've gotten around to fixing up the reference library somewhat, although it still lacks any kind of searching or sorting, not to mention pagination.
