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

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 L^AT_EX, 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.

This document was translated from L^AT_EX by H^EV^EA.