Solaronite: and Now with Non-VCS Backend, Too!

Lack of robust version control for content is a signal failing of many popular content managers, so what's up, Solaronite, are we taking a step backward? It's not what it looks like, really, I can explain! Non-VCS backend for content is actually a really cool feature, in a surprising way, as I shall elucidate now.

Nice though a git repository is for storing weblog content, I have found it to have one persistent annoyance. Generally when I finish writing an entry, I post it and then do a few rounds of proof-reading in the browser. I catch a lot of little things this way, as well as adjust the prose style after seeing the entry in published form. I get into a cycle where every time I want to change one little thing, I go back to the file, make the change, commit to git, then git push to the server, and re-read. This can go on for kiloseconds. I consider that I am wasting time creating and pushing commits for trivialities. I can run a copy of the website locally, when I think of it, which at least saves me the steps of a git push every four minutes. If only I could take out the commit step as well…

This is where the non-version-controlled backend comes in. It's called <backend-filetree>, and it just lists and serves files straight from a filesystem, rather than from a VCS. Sounds pretty conventional, right? The point is, the content manager can use either vcs or non-vcs, as the situation demands. Local editing is made more efficient by using a non-vcs backend on the git work-tree, but when it's time to publish, we still have git and all of the advantages it provides. At the nuts-and-bolts level, the application is just looking at the hostname of the machine it's running on, and saying, for this machine use filetree, but for that one use git. I do my editing with instant preview locally, then check in and push the changes at leisure. It also brings the ability to see instant previews of files that haven't been checked in at all, which is useful for drafts. All in all, this kind of convenience is the way blogging should work — at least it's much less of a hassle than before.

The filetree backend is also potentially useful in other ways, some which I have been thinking about since long before this latest idea arrived. For example, automatically integrating directories like /screenshots, /lifeshots, /comics, etc, into the blog. That will be a cool feature, but I think that before I can add it, there are some lower level things that I need to put in place first, so it's a little further off. With the improvement to my editing workflow as described here, the non-VCS backend gets the status of being a really cool feature, today.