Recommendations for config file revision control

[Maxim Khitrov]

On 6/1/07, Kevin Downey <redchin at gmail.com> wrote:
> On 6/1/07, Maxim Khitrov <mkhitrov at gmail.com> wrote:
> > Hi everyone,
> >
> > I'm currently setting up a new server, and I'd like to keep track of
> > all changes made to various config files (in /etc, /usr/local/etc, and
> > a few other places perhaps). My first thought was to setup a
> > subversion server which would contain the partial directory structure
> > that matches that of the server's starting at /. It would contain
> > versioned copies of all the configuration files that I want to keep
> > track of in their appropriate locations. What I would do then is write
> > a hook for subversion that will issue an automatic export command
> > (don't want .svn directories everywhere) every time a commit is made
> > to the repository. So to edit some configuration file I would first
> > checkout a working copy of the repository to some other location, make
> > the change and commit it. The server would be automatically updated
> > with the new file and I would be able to keep track of every change.
> >
> > This seems like a decent strategy to me, but before I go off writing
> > the scripts and setting up the server I wanted to ask what you guys
> > might be using to keep track of the server configuration (backups
> > don't count)? Is there an easier way of doing the same thing, for
> > example, eliminating the need to do a working copy checkout first?
> > Perhaps a way to monitor certain files for changes, and automatically
> > commit them every time a change is saved. I'd be glad to hear any
> > suggestions you might have in this regard. If possible, I'd like all
> > the versioned files to contain an id string, so that it's easy to
> > determine when the file was last changed and by whom, but this is
> > optional. For the most part I just need a way of going back to
> > previous versions.
> >
> > Thanks,
> > Maxim Khitrov
>
> What is the objection to having the metadata directories (.svn) everywhere?

Well to be honest, I just really don't like that design. I think the
metadata should be separated out from the data, and placing .svn
directories into each directory of the project seems like a bad idea
to me. I understand why it was done this way, but I wish that some
extra effort was put in to consolidate all that information into
perhaps a single .svn directory in the root of the project. That, and
since they keep copies of the original files it also creates
additional storage requirements, but for storing configuration files I
don't really care.

I did just think of another thing I could do. What if I create a new
directory on the server, and move all configuration files from their
original location to this directory. I then make then make it into an
svn working directory, and in place of the original files put symlinks
that point to the corresponding file in the working directory. This
would mean that I no longer have .svn directories all over the file
system, there is just one working directory that is separate from
everything else. Instead of an export operation I could have the hook
script do an update, and this would also give me a rather simple way
of editing the files locally on the server (plus it has the advantage
of quick access to all important files without having to constantly
move from /etc to /usr/local/etc).

Does this seem like a decent idea to try and do? Might some software
have a problem with its configuration file being a symlink to some
other location?

> devel/bazaar-ng is rather nice, and distributed vcs is very flexible.

Will take a look at this as well, thanks.