Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RCS for managing config files

Jerry Feldman wrote:
> Tom Metro wrote:
>> That's precisely what RCS prevents. The first person to check out and 
>> lock the file has exclusive write access until they unlock it.
> What CVS, subversion and other source control programs do is to allow
> multiple checkouts in a file. The problem occurs when there is a
> conflict. Resolving merge conflicts can be time consuming, but is a
> necessary task in a large development process. 

Unless you are maintaining multiple systems, I tend to think that CVS or 
Subversion is overkill for the task of maintaining configuration files.

While most config files are located under /etc, they can and do show up 
elsewhere, and it is trivial to check them into RCS wherever they happen 
to be. With SVN and CVS you have to give some thought as to where they 
should live in the repository.

/etc is also full of stuff that either isn't a config file, is 
automatically generated, or doesn't need to be under revision control. 
All of that stuff then becomes clutter to a tool like SVN or CVS that 
expects to "own" the working directory, and will either lead to nuisance 
diffs or a pile of exclusion rules.

In addition, unless you are dealing with multiple systems, the whole 
simultaneous editing model, which is what leads to the need for merges, 
makes little sense. Each administrator working on the system doesn't 
have his own private working directory. There is only one live /etc tree 
used by the system. For this reason, the older style method of exclusive 
locks used by RCS makes more sense.

David Kramer wrote:
> ...I've never been able to determine through research whether the
> .svn directories would interfere with scripts that traverse 
> directories...

When I started using RCS files, which I typically put into an RCS 
subdirectory, I looked into this. In most cases you can easily determine 
this by looking at the script or source, if not the documentation.

On Debian at least, this has never been a problem, and I've used RCS 
directories with cron (cron.{daily,weekly,etc.}), logrotate.d, and other 
directories that get enumerated. I've also been known to create a HOLD 
or DISABLED subdirectory as a place to move scripts I don't want ran, 
which works as expected.

> My intuition tells me that these scripts would skip dotted directories...

In every case I've seen, they skip all directories. They only do a 
one-level deep traversal.


Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile:

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /