This isn't necessarily a programming question, however it pertains to CVS so I think I'm more likely to get a response here.

I've always tracked changes to my installations using text files, spread sheets, old vs. new file backups, package caches, etc. I do this so I can reproduce my system using only those things after initial distro installation, plus whatever /home backups I've made. I can't even count how many methodology iterations I've gone through.

It occurred to me just now that CVS might be a good tool for tracking changes since it stores changes as a series of patches and can catch changes that I didn't notice. Has anyone ever tried using it to track /etc changes? I think I might track /etc, /usr/etc, /usr/local/etc with it, keep some sort of minimal log of personal notes, and a cache of post-distro packages. Does anyone see a problem with this? Thanks.
ta0kira

Hi.

See the older article below on using CVS for keeping changes to home.

I use an RCS script to track transient changes as I am developing. I use subversion for my LAN repository. Luckily /etc will probably not change structure much, because CVS doesn't deal with directories as well as subversion does.

Best wishes, and keep us posted if you decide to do this ... cheers, makyo

http://www.linuxjournal.com/article/5976

It's a good idea, but it's not perfect. I've used CVS to do this on boxes before with a cron job to email me a filtered diff report once a week. The worst parts are setting it up for the first time (it's tedious) and filtering the report. For example, some apps install a bunch of symlinks which I can't be bothered tracking (they'll get installed with the package or any updates) so I filter the diff report through sed to get rid of that info.

There's plenty of ways to manage something like this - try it (and other ways as well) and find out if it suits the way you work...

I tried it with etc files, but I can't remember exactly why I abandoned it.
I think I was on Suse at the time and with all the packages there were about
20 zillion conf files plus like all the kde gnome conf directories
and all the management of what and what not to add to the repository and .cvsignore life was too short.

I use this method at work though with my programming and it works OK.
I have a permanently checked out work tree with my .profile and shell and perl scripts soft linked to it
and it works ok.

So if you have the patience it should work.

(cont)

as previously said, apps add and change files all the time so you may forever
get spurious cvs diff messages.

but, maybe have a seperate ETC dir with files you explicitly change
linked to the real /etc.

hmmm, I might try again myself

I like the concept and should try it out on my FC4 server at home. I'm becoming quite familiar with Subversion and it's tags, so adding Subversion / CVS tags to some conf files could be interesting to see the "latest version number", and "last changed datestamp".

Question is, do you automate the "svn commit", or leave that as a manual thing? If it's automated, how frequently should you do it? Put it in cron.daily? Hourly?

Hi.
I think I understand why you would use a link for files like .profile, but why for the scripts?

I've found that adding the checked-out directories to the PATH seems to work well ... cheers, makyo

er, laziness probably.
For instance in my ~/bin I have some binaries as well, so I don't want it as
a cvs dir or I have to manage what to ignore and what to keep etc.

I just like to keep all my general programming and scripting under 1 tree, ~/w
and link them out from there. links are good :-)

I am just too lazy, this way it needs minimal management.

Hi, bigearsbilly.

A colleague and I have been wrestling with issues like this for some time. We have used some ideas from Martin Blais: http://furius.ca/projects/ We've done some work setting up scripts so that one could go to a new contract job and easily begin to use one's own toolset. We're not quite done yet. We both deal with many different hardware-OS platform combinations, so Blais' work has been very useful.

We have begun a sourceforge project, but have done almost nothing on it so far. Lots of hours of discussion and experimentation, however .

Currently, I separate binary-executables from scripts. At one time I mixed them in the same directory, but I think I've concluded that separation is the best approach if we're going to be using version control.

My recollection is that both cvs and subversion ignore binary-executables by default ... cheers, makyo

I'm going to try this with Subversion, just for files in /etc. Up till now I've had the files in CVS, but checked them out to a separate place and copied them over, with all the possibilities for error that implies. The problem isn't so much telling Subversion what to ignore, as telling the programs that use the files to ignore .svn directories. Most of them do, I think, especially if they use run-parts. Subversion is a bit better than CVS in this respect because it hides its directory with a dotted name.