ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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

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

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.

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?

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.