VCS == CMS or How Git is the Last Filesystem You’ll Ever Need

David Rush

So I have set up a blog. And my CMS is a lash-up of
Git,
HeVeA, and
xsltproc, held together with random
bits of TCL. And this is the first
post!

Ok, enough gushing with excitement, it’s all just code. But even so,
it was really fun to see just how well the pieces came together. The
biggest difficulty was getting the Git post-receive hook to work
correctly. Every single time I write one of those it turns into
pain. Perhaps I just don’t write them often enough to remember all of
the details.

Git has essentially become my default
filesystem. It runs everywhere, and has backups built into the
essential architecture of the system. With this last escapade, I have
made the jump to where I no longer create any text files outside
of Git. I even stick a lot of images and other precious binaries in
Git, even though it is not terribly efficient with them (and in
fairness with git-annex
finally running on Microsoft, even that isn’t be an issue).

So you get version control and replication for free, but the killer is
the fact that you also get scripted events. Which has led directly to
this blog. Whenever I git push from my blog Git repository, my
web-server is now set up to copy/transform the files into appropriate
web content. So I can write posts in nice friendly
LATEX, custom XML schemata
Markdown, or
even in straight HTML if I feel the need, all while using any plain
text editor (coughEmacs).

As I mentioned earlier, setting up git hooks can be something of a
pain. This time I was using TCL as the scripting language, so I actually
expected it to work a little bit better than previously (when I had
worked in bash). Alas, once again, the number of implicit assumptions
connected with gluing multiple systems together inside an event-driven
daemon got the best of me for a little bit. And while it
may be possible to have a quick test turnaround, it is still
quite easy to have the test environment diverge from the actual
run-time environment – yielding invalid results. Apparently this is a
well-known problem with Git,
or to be fair, the
Git hooks
documentation.

A second problem is that the publishing infrastructure that I have set
up depends on having a clean pipeline. This is probably not a
good thing, but it does mean that the system can be put together with
much less software. But you pay the cost in extra testing pain, of
course. All told, I have just about 100 lines of code in this project,
so I think that it still counts as a successful engineering
trade-off. I imagine that as it grows anad accumulates features, that
I will have to revisit the design and implementation with more care,
but for right now, its a pretty cute, and quick hack.