Configuration version control software

Question

I know some people like to put their /etc under version control with CVS or hg or something, to make it easier to recover if they misconfigure something. I think this is kind of overkill, though. For one, you don't really need "distributed" or "centralized" version control, you just need to control the version. And for another, version-controlling the entire /etc doesn't really make sense considering that you're usually only working with a few files at a time, which you would generally control separately. So, I came up with the idea for a VCS specific to managing your system configuration. I'm going with the name Tessen for now since it sounds cool.
The two basic concepts involved here are applications and snapshots. An "application" refers to a particular set of config files managed by Tessen. For example, the pacman application would own pacman.conf, makepkg.conf, and pacman.d (a directory). Ownership in this context means that it will automatically track changes to the contents of the files and folders. (Each application has an active snapshot, which is basically "the last one you saved or reverted to.")
A "snapshot" is how an application's config files looked at any given time. A snapshot has a number (since it's not distributed, a simple autoincrementing integer will work), a timestamp (for obvious reasons), an action (to indicate exactly what caused this snapshot to be taken - for the user manually saving it would be "save", if it was installed by a package manager, "install", etc.), a note (if you feel like it - a good sysadmin would always have one), and the files' contents. (You can also add additional notes to snapshots after the fact, but this won't affect the note that was saved with the snapshot in the first place.)
Anyway, the workflow would run something like this:
"tessen newapp pacman pacman.conf makepkg.conf pacman.d". Tessen creates a new application named "pacman" that owns pacman.conf, makepkg.conf, and the directory pacman.d. (Tessen would automatically save a snapshot at this point consisting of the current contents of said files. That would be snapshot #1.)
Make changes to the configuration, like using aria2c as the transfer command.
"tessen save pacman -n 'set XferCmd to aria2c'". Tessen will take a snapshot of all the files owned by pacman and save that, making it #2.
DOOM! You forgot that you don't have aria2 actually installed, and now that XferCmd is aria2c you can't install it! (This is just a contrived example.)
"tessen revert pacman". Since you're at #2 but haven't made any changes, it will switch you back to #1. (If you had made changes, it would reset to #2 instead.) All necessary files will be reverted.
Now you can "pacman -S aria2" and make sure it works this time.
You could edit it manually to set it back to aria2 (which if you saved it would make it #3) but it's easier just to "tessen revert pacman 2". revert jumps back one step by default, but you can tell it to revert to anything. Then the next change you make would be #3.
One major thing about the design I haven't quite decided would be how ownership is stored, and what to do if you change the ownership and try to revert to an older snapshot. That would be tricky to figure out. Still, what do you think about this approach?

Answer 1

ewaller wrote:I think I'm missing something :-/
I know the OP dismissed git and hg at the outset -- but why?  It seems to me they are ideal for just this sort of thing.  On this machine, I do have an Hg archive living under /etc.  Being Hg, it is simple to push that off to other systems and keep them synced (or not).
Perhaps tessen could wrap git or Hg?
The reasons I had for not using a traditional DVCS (as much as I love them) include:
A VCS in all of /etc would manage your configuration as a whole. Tessen lets you manage each application separately without awkwardness.
Also, there is stuff in /etc that isn't really configuration (I'm looking at you, /etc/bash_completion!). You could get around this by simply not "hg add"ing those files, but it does make it trickier. (Though in an ideal world, each app would store its configuration in a separate directory and things like the completion scripts would be in /share or /usr/share.)
Finally, if you're using a DVCS so you can sync configuration, this would actually be better. For example, if you're trying to share the Apache and CouchDB configurations between your boxen, you have no way to keep out any other files you might have added (like, say, fstab).
Really, it's mostly just that the concepts behind Tessen map more clearly to the problem than those in hg or git. At least in my mind. Although using a DVCS as the storage backend would be interesting...
fukawi2 wrote:What language are you planning on writing this in?
Probably Python. (My original concept would use SQLite as the database.)