/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
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
- 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.)