Wandering Thoughts archives

Why keeping /etc under version control doesn't entirely help

One of the reasons that I'm not too enthused with various schemes to put /etc under version control is that they don't really give me what I really want out of the whole exercise.

First, let's assume that you have somehow divided your /etc repository up into a lot of separate modules in order to keep things straight. Without loss of generality we can look only at the evolution of a single module on a single system over time. The problem is that you really have three separate strands of development in action:

• the evolution of the system's stock version of the files, if there is any.
• the abstracted evolution of your general local version; what sort of changes and customizations you make and how you change this.

• the merger between the first two, where you customize your general local changes for the current base state of the system's files.

(If you are trying to have several different systems or sorts of systems use the same repository, things get even more tangled.)

A purely time-based history will get you some tangled mixture of these three strands (probably some of them will only be implicit). It is possible to use branches, rebasing, or both to try to keep the strands separate, but at that point you start needing significant tool support (or mistake-prone manual intervention) because you can't just automatically checkpoint the state of /etc after any change; you need to figure out the context of each change and put it in the appropriate branch and then do the remaining work.

(There are still good reasons to have time-based snapshots of all of your configuration files along with some commentary on what changed and why, but there are a lot of mechanisms for doing that. Putting /etc under version control may or may not be the simplest one in any particular environment.)