Date: Fri, 1 Jun 2007 19:35:22 -0400 From: "Maxim Khitrov" <mkhitrov@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: Recommendations for config file revision control Message-ID: <26ddd1750706011635s285860c1p57c360af69596ecc@mail.gmail.com> In-Reply-To: <1d3ed48c0706011603k5948510ctb49e399aa2ace22f@mail.gmail.com> References: <26ddd1750706011227g224eaa1dh93233400c704595e@mail.gmail.com> <1d3ed48c0706011603k5948510ctb49e399aa2ace22f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/1/07, Kevin Downey <redchin@gmail.com> wrote: > On 6/1/07, Maxim Khitrov <mkhitrov@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26ddd1750706011635s285860c1p57c360af69596ecc>