Recommendations for config file revision control

[Maxim Khitrov]

On 6/3/07, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> On 2007-06-02 21:45, Maxim Khitrov <mkhitrov at gmail.com> wrote:
> > Here's an update on what I ended up going with. I decided to go
> > with my idea of moving all configuration files to a common
> > directory, but with a bit of a change. I created /config and
> > under it base/ and user/. Everything in base/ comes from /etc
> > and /boot, and the rest goes under user/. I didn't want to mix
> > the two. So then I created a new subversion repository, but I
> > set permissions such that only root can read or write to
> > it. Basically I decided to forbid anyone on the outside from
> > getting their hands on the repository contents, since it will
> > be storing things like master.passwd and other sensitive data.
> >
> > Once all this was in place I moved all configuration files to
> > their appropriate locations in /config and created symlinks in
> > their original location. Everything under /config was then
> > imported into the subversion repository using the file://
> > method. Since I forbid anyone from doing a check-out of the
> > repository to some external location, I don't need to worry
> > about file updates except when they are updated in
> > /config. This simplifies things. What I did to keep the
> > repository up to date was create a simple sh script that is run
> > by cron every 10 minutes. The script simply issues 'svn ci
> > --non-interactive --message "Automatic commit"' command in the
> > /config directory. So any changes made to the configuration
> > files are automatically recorded every 10 minutes.
> >
> > This works well, but does have a few flaws. First of all, when
> > I edit files from sftp I have no way to add a meaningful
> > message to the commit. Not a big deal, and I can always do a
> > manual commit if I had to. The other thing is that this script
> > will not auto-add files to the repository. Any new
> > configuration file that I'd like to have monitored first gets
> > moved to /config, then has a link created in the original
> > place, then is added to the repository via 'svn add'. A bit
> > more work, but I think it's fine. Technically I can automate
> > the process of adding and removing files from the repository by
> > using svn status output, but at this point the extra work isn't
> > worth it. The bigger problem is the fact that subversion does
> > not store owner and permission settings. That means that if I
> > ever want to delete the /config directory and recreate it, I
> > lose all permissions on things like master.passwd. What I did
> > was add chown and chmod commands to the monitor script for all
> > files that had non-standard permissions. So those get run along
> > with the svn ci command every 10 minutes. The alternative was
> > to use subversion properties, have the script parse those and
> > apply the appropriate settings. However, since the permissions
> > have to be set manually anyway there is no advantage to this
> > over the monitor script, which is also versioned.
>
> The permission and ownership problem is also one of the issues
> which Subversion (or other SCMs) do not solve for base-system
> binaries too.
>
> See for example the thread:
>
>     Using Subversion for binary distribution?
>
> which was recently present in `freebsd-current'.
>
>

Hm... I wish I found that thread earlier on, because I actually missed
the reference to Mercurial on wikipedia. I've been playing around with
it over the past few hours and so far I think it might actually be a
better solution than svn. It keeps just one .hg directory in the root
of your project, which means that I don't need a separate storage
location to isolate the versioned files. In addition to this, I can
add an ignore pattern of .* (all files), which means that hg will only
worry about the files that have been manually added to the repository.
I'm rather intrigued by this system, but I'm going to play around with
it a bit more in my test environment. Has anyone ever heard of
corruption issues with hg?

I guess it still suffers from the same problems with setting file
permissions, but the hooks are there, so I'm not worried about that.