Re: Track /etc directory using Subversion

Alexander Skwar wrote:

> I'd like to track the contents of my /etc directories with a version
> control software, so that I can later on easily see what's been changed
> when and also why (in the rare case, that a good commit message has been
> supplied *G*). To do this, I'm thinking about using Subversion.

I don't have an answer, but was just about to ask a similar question.

> One thing that kind of stops me, though, is that Subversion, by itself,
> doesn't store "metadata" of tracked files; metadata like atime/ctime/mtime,
> ownership (user/group) and maybe ACLs. For tracking /etc with Svn, at least
> time and ownership information would need to be stored, though.

Files in /etc are usually small enough that you could (and probably
should) have a separate backup mechanism if you actually need to restore
them and svn could be used for 'human' views of content changes. But,
it would be nice to have the same ability to see history of metadata as
well as content.

> I found the "asvn" script in the contrib/client-side directory. This
> script breaks when it has to deal with directories/files which have
> a space in the filename :( Does anyone maybe have a fixed version?
>
> How do you guys deal with this problem? And if Svn isn't suited to track
> /etc, would somebody maybe know of a tool which is suited for this job?

I've been keeping a hand-picked set of files (mostly dns zones and
tftp'd in config files from routers and switches) under CVS control for
years, with viewcvs providing a web view and the ability to easily diff
any selected versions. I'd like to update this to use subversion and
viewvc but was hoping that some higher level framework was available or
at least some 'best-practice' advice. The big problem I see with
something like a whole /etc directory is that you need to maintain the
.svn subdirectories which isn't going to fly when you completely replace
your OS version - and that's when you really need the diff against the
previous. Has anyone tackled this with svk handling the end point so
as not to need the .svn's, but working against a mirrored checkout from
subversion? Ideally, this could treat each machine's /etc as a branch
from some initial common parent so duplicates would be handled
efficiently and you'd have the ability to diff among different targets
as well as revisions within a target.

-- 
    Les Mikesell
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org