Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

CVS as Unix Sysadmin Tool

News Configuration Management Recommended Links Reference FAQs Recommended Papers
Unix Configuration Management Tools Presentations Admin Horror Stories Unix History Humor Etc

There is nothing magic about Version Control. It is just an insurance against some unfortunate events. The simplest way suitable for small project is to substitute backups for version control and assume that daily backups will save you from troubles as you can restore previous versions of the files from the archive of your sources tree. But you can go further and create backups of each version you created. By keeping a record of all the changes, you've built up a complete history of all the changes done to that file. Why this useful?

By keeping a history of your changes, you're keeping a record of all the work you've done. You have the record of  things you've tried so you can avoid reinventing the bicycle later. You also have all the bad things you've done, so you can avoid them later. History is a great teacher if you keep records. 

In essence version control is a more fine granular form of backups (and you should regularly back up your work). If all of your files are under version control and you regularly commit your changes, a complete snapshot of your work exists in a different location then your working directory and you source tree can survive the crash of the local hard drive with minor damages. If you accidentally delete important file from your work tree or a Perl script runs rampant, you can always retrieve the latest version from version control system.  Some editors permit storing copies of each save operation as a new version, which might actually be an overkill.

Version control can be done in various ways using different systems. CVC is just one of them and there are many others some of which are better (subversion) some of which are more friendly to multiple changes in the source tree (arch). But CVS is often good enough and is the only tool officially approved for particular project. So whether you want or don't, you are stuck with it.  CVS is an old system and internals are rather ugly but it works.

Many large open source projects, including KDE, GNOME, and Mozilla use CVS. Most open source hubs such as SourceForge support it as a service. Despite its popularity, CVS has its limitations. For example, it does not support file and directory renaming. Binary files are not handled well.

CVS is not distributed and the commits are not atomic. On the plus side, CVS is extensively documented in its own online book and in many online tutorials. There are also many graphical clients and add-ons available for it.

NEWS CONTENTS

Old news ;-)

[May 24, 2007] Cultured Perl Managing Linux configuration files

The idea of storing files without full path is questionable: "In my configuration scheme, each configuration file is in a single directory or in one of its subdirectories. The configuration files are be named uniquely, and the directories denote machines or platforms rather than location."

Contents: The Plan Setting up CVS Automatic updates and commits Organizing your new configuration Conclusion Resources About the author Rate this article Related content: Cultured Perl: Application configuration with Perl Understanding Linux configuration files Debugging configure OpenSSH key management

Teodor Zlatanov ([email protected])
Programmer, Gold Software Systems
10 Jun 2004

The average developer spends more time navigating, learning, and debugging configuration files than you'd expect. But you can save that time -- and loads of energy and frustration -- with one of the tools you probably use every day: your CVS tree. Take these tips on backing up, distributing, and making portable your peskiest Linux™ (and UNIX®) config files.

Working with configuration files can be a bewildering part of using Linux and computers in general. No standards exist, though several have been proposed. For example, Samba and rsync use INI-style configurations; passwd is in a decades-old colon-separated format that doesn't allow colons in any field; sudo comes with a visudo program to keep people from entering wrong information in the sudoers file; Emacs uses Lisp for configuration files. And the list goes on...

Now, I'm not complaining about the variety of configuration files. I understand the historical and practical reasons for this Configuration Tower of Babel. Changing the Samba configuration format, for instance, would annoy thousands upon thousands of administrators. In another example, Emacs' internal language is Lisp, a powerful high-level language, so using anything else for Emacs configuration files would be ridiculous.

No, my point is the effect all this variety has on the Linux user: a large portion of a Linux user's computer time is spent learning, writing, and debugging configuration files. Thus, it is useful to have a system in which these configuration files (1) are backed up automatically, (2) are distributed automatically, and (3) work on multiple flavors of UNIX and distributions of Linux. This article explains how to achieve the first two goals, and gets you started on the road to achieving the third one.

The Plan

We'll use CVS to hold the configuration files. Feel free to use any other versioning system. Subversion is gaining popularity quickly. The FSF has GNU tla (GNU arch), another nice versioning system. The essential features you need are provided by all those and many others, including the non-free ones like Rational® ClearCase®.

In my configuration scheme, each configuration file is in a single directory or in one of its subdirectories. The configuration files are be named uniquely, and the directories denote machines or platforms rather than location. Thus, the file name maps uniquely to a location in the filesystem. For example, passwd will always be used for /etc/passwd, while cshrc will be used for /home/tzz/.cshrc for user tzz.

For a few programs I use daily, I'll show how I handle multiple platforms with the help of my configuration system and changing the configuration files themselves.

All the examples I show use the C shell to set environment variables. Modifying them to use GNU bash or something else should not be terribly difficult.

Setting up CVS

You probably already have CVS installed on your machine. If not, get it (see the Resources section) and install it. If you are using another versioning system, try to set up something similar to what I show below.

First of all, you need to create a CVS repository. I'll assume you have access to a machine that can be used as a CVS server through OpenSSH or Pserver CVS access (Pserver is the communication protocol for CVS; see Resources for more information). Then, you need to create a module called config, which I will use to hold the sample configuration files. Finally, you need to arrange a way to use your CVS repository remotely non-interactively, through OpenSSH, Pserver, or whatever is appropriate. This last point is highly dependent on your particular system administration skills, level of paranoia, and environment, so I can only point you to some information in the Resources. I will assume you have configured non-interactive (ssh-agent) logins through OpenSSH for the rest of this article.

Listing 1. Set up the CVS repository on a machine

# assume that /cvsroot is your repository's home
> setenv CVSROOT /cvsroot
# this will use $CVSROOT if no -d option is specified
> cvs init
# check that it worked
> ls /cvsroot
# you should see one directory called CVSROOT
CVSROOT

Now that the repository is set up, you can continue using it remotely (you can do the steps below on the CVS server, too -- just leave CVSROOT as in Listing 1).

Listing 2. Remotely add the config module to CVS

# user tzz, machine home.com, directory /cvsroot is the CVSROOT
> setenv CVSROOT [email protected]:/cvsroot
# use SSH as the transport
> setenv CVS_RSH ssh
# use a temporary directory for the module creation
> cd /tmp
> mkdir config
> cd config

# tzz is the "vendor name" and initial is the "release tag", they can
# be anything; the -m flag tells CVS not to ask us for a message

# if this fails due to SSH problems, see the Resources
> cvs import -m '' config tzz initial
No conflicts created by this import
# now let's do a test checkout
> cd ~
> rm -rf /tmp/config
> cvs co config
cvs checkout: Updating config
# check everything is correct
> ls config
CVS

Now you have a copy of the config CVS module checked out in your home directory; we'll use that as our starting point. I'll use my user name tzz and home directory /home/tzz in this article, but, of course, you should use your own user name and directory as appropriate.

Let's create a single file. The CVS options file, cvsrc, seems appropriate since we'll be using CVS a lot more.

Listing 3. Create and add the cvsrc file

> cd ~/config
> echo "cvs -z3" > cvsrc
> echo "update -P -d" >> cvsrc
> cvs add cvsrc
# you really don't need log messages here
> cvs commit -m ''
> ln -s ~/config/cvsrc ~/.cvsrc

From this point on, all your CVS options will live in ~/config/cvsrc, and you will update that file instead of ~/.cvsrc. The specific options you added tell CVS to retrieve directories when they don't exist, and to prune empty directories. This is usually what users want. For the remaining machines you want to set up this way, you need to check out the config module again and make the link again.

Listing 4. Check out the config module and make the cvsrc link

> cd ~
# set the following two for remote access
> setenv CVSROOT ...
> setenv CVS_RSH ...
# now check out "config" -- this will get all the files
> cvs checkout config
> cd ~/config
> ln -s ~/config/cvsrc ~/.cvsrc

You may also know that Linux allows for hard links in addition to the symbolic ones you just created. Because of the limitations of hard links, they are not suitable to this scheme. For instance, say you create a hard link, ~/.cvsrc, to ~/config/cvsrc and later you remove ~/config/cvsrc (there are many ways this could happen). The ~/.cvsrc file would still hold the old contents of what used to be ~/config/cvsrc. Now, you check out ~/config/cvsrc again. The ~/.cvsrc file, however, will not be updated. That's why symbolic links are better in this situation.

Let's say you change cvsrc to add one more option:

Listing 5. Modify and commit cvsrc

> cd ~/config
> echo "checkout -P" > cvsrc
> cvs commit -m ''

Now, to update ~/.cvsrc on every other machine you use, just do the following:

Listing 6: Modify and commit cvsrc


> cd ~/config
> cvs update

This is nice and easy. What's even nicer is that the CVS update shown above will update every file in ~/config, so all the files you keep under this CVS scheme will be up-to-date at once with one command. This is the essence of the configuration scheme shown here; the rest is just window dressing.

Note that once you've checked out a module, there's a directory in it called "CVS." The CVS directory has enough information about the CVS module that you can do update, commit, and other CVS operations without specifying the CVSROOT variable.

Automatic updates and commits

For automatic updates and commits, I have written a very simple Perl program, maintain.pl. The longest part of the program is the help text, so you can imagine it's not full of complex code. I will go through it regardless, but keep in mind that a shell script could do the same job if needed.

The only thing maintain.pl does not do is make the symbolic links. Since that has to be done just once, and on some systems you do not want the links wholesale, the complexity of the task compared to the simplicity of doing it manually was simply too much. I know because I wrote the symbolic link code and got rid of it later.

I had to write and maintain yet another configuration file that mapped out many filenames. There were many exceptions; for example, two Linux and Solaris systems I use have radically different setups. There were just too many things to worry about, and I found that manually installing the links was much easier. Of course, your experience may vary -- I encourage you to try to find the most appropriate approach for your own environment.

The maintain.pl script begins with the usual definition of configuration options, loading of command-line arguments, and help text.

Listing 7. Preliminaries in the maintain.pl script

#!/usr/local/bin/perl -w

# {{{ modules and constants
use strict;
use AppConfig qw/:expand :argcount/;
# }}}

$| = 1;				# autoflush the output

my $config = AppConfig->new();
$config->define(
 'HELP'     =>
 { ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'H'},
# update level, higher checks out more
 'LEVEL'    =>
 { ARGCOUNT => ARGCOUNT_ONE,  DEFAULT => 5 },
 'CONFFILE' =>
 { ARGCOUNT => ARGCOUNT_ONE,  ALIAS => 'F',
   DEFAULT => glob("~/config/maintain.conf") },
 'CVS'      =>
 { ARGCOUNT => ARGCOUNT_ONE,  DEFAULT => 'cvs' },
 'CVS_RSH'  =>
 { ARGCOUNT => ARGCOUNT_ONE,  DEFAULT => 'ssh' },
 'UPDATE'   =>
 { ARGCOUNT => ARGCOUNT_HASH },
 'DRYRUN'   =>
 { ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'N' },
 'COMMIT'   =>
 { ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'C' },
);

$config->args();
if (-r $config->CONFFILE() && -f $config->CONFFILE())
{
 $config->file($config->CONFFILE());
}
else
{
 print "The file " . $config->CONFFILE() .
       " was not readable, skipping\n";
}

if ($config->HELP())
{
 print <<EOHIPPUS;

$0

Run $0 without any arguments to load
@{[$config->CONFFILE()]}
and update everything in it at level
@{[$config->LEVEL()]} or less.

Switches:
 -level (default @{[$config->LEVEL()]}) :
   check out everything at this level or less

 -help (-h) : print this help

 -conffile (-f, default @{[$config->CONFFILE()]}) :
   load this configuration

 -cvs (default @{[$config->CVS()]}) :
   where to find the cvs program

 -cvs_rsh (default @{[$config->CVS_RSH()]}) :
   sets the CVS_RSH environment variable

 -update : populate the UPDATE hash in the configuration
           file or like this:
           -update /home/tzz/           see below for explanation

 -commit (-c) : don't just update, also do a commit of
                anything changed

 -dryrun (-n) : don't run anything, just test directories
                and levels

Configuration file:

Very simple AppConfig format; everything in the switches can be
specified in the configuration file as well, e.g.

COMMIT = 1
UPDATE /home/tzz/config = 0

The example above says that /home/tzz/config will be updated at level
0 or higher, and that you always want to commit when you run this
program.

EOHIPPUS

 exit 0;

}

$ENV{CVS_RSH} = $config->CVS_RSH();

If you are unfamiliar with the AppConfig module, you should check out the Resources section for useful info on managing configurations.

I do a glob() call to determine the default CONFFILE, because the user's home directory could be anywhere. If the CONFFILE contains invalid data, AppConfig automatically kills the whole program (this can be changed to be just a warning). The script can even run without a configuration file.

After printing out the help text, I set the CVS_RSH environment variable to the appropriate value (defaults to ssh). This is so that the user does not have to set that environment variable in some other way, which is especially convenient for users who put maintain.pl in their crontab.

After all these preliminaries, let's look at the heart of the script:

Listing 8: main loop of maintain.pl

foreach my $spot (keys %{$config->UPDATE()})
{
 my $level = 0 + $config->UPDATE()->{$spot};
 next if $level > $config->LEVEL();
 print "Spot $spot, Level $level\n";
 chdir $spot;
 if ($config->DRYRUN())
 {
  print "Not updating due to DRYRUN\n";
 }
 else
 {
  system($config->CVS() . " -q update");
 }

 if ($config->COMMIT())
 {
  if ($config->DRYRUN())
  {
   print "Not committing due to DRYRUN\n";
  }
  else
  {
   system($config->CVS() . " commit -m ''")
  }
 }

}

This is a simple loop. I run through every spot, which is really a directory, and do a cvs update if the spot's level is less than or equal to the LEVEL configuration variable, defaulting to 5. In addition, if the COMMIT flag is set, I do a cvs commit -m '', which commits all changes with an empty log message. In fact, if it weren't for the DRYRUN flag, this loop would be just a few lines long.

I use system() with the string form instead of the multiple argument form. You could do it the second way -- see perldoc -f system for details on the usage of this function call.

Also, I don't check the result of the system() call, because it's unnecessary. There's nothing maintain.pl can (or should) do in the case of a CVS update or commit problem, since these are crucial configuration files we don't want to update blindly.

The configuration file is simplicity itself:

Listing 9. maintain.conf

# the number is the update level
UPDATE /home/tzz/emacs = 0
UPDATE /home/tzz/config = 0
UPDATE /home/tzz/articles = 1
UPDATE /home/tzz/gnus/gnus = 1

Remember you can set any AppConfig variable here, so you can override the default LEVEL or CVS_RSH, for instance. I update my Emacs, config, articles, and gnus directories through maintain.pl, but their update levels are different to reflect the frequency with which I update (I do level 0 twice every day and level 1 once daily).

Organizing your new configuration
This section will cover my personal experiences with using the configuration system you've set up so far. Take ideas freely, but remember that my personal setup is not right for everyone.

I keep directories based on machines and operating systems, as specific as they need to be. For instance, I keep my Linux-specific configurations under "linux" but, because my home machine "heechee" has a specific keyboard, I have a heechee directory as well for the heechee-specific configurations.

The overriding rule, though, should be that if you can express a configuration in one file instead of multiple versions for multiple platforms, do it. Otherwise you'll spend most of your time maintaining two or more versions of the same file, and that's not fun.

Let's start with an example from my cshrc file, which has one version for all machines. I take advantage of the C shell language's built-in decision logic to make alternate decisions:

Listing 10. Define the precmd for various platforms

switch ($OSTYPE)
 case "solaris":
 case "SunOS":
  alias precmd '/bin/echo "\033]0;${HOST}:$cwd\007\c"'
 breaksw
 case "linux":
  alias precmd 'echo -n "\033]0;${HOST}:$cwd\007"'
 breaksw
endsw

The commands above specify different versions of the same thing. The Linux echo needs an -n switch to avoid printing a new line, while the Solaris version needs a \c at the end of the string. The effect of this is to set the title of an xterm window to HOST:/DIRECTORY whenever a prompt is printed.

Clearly, whenever you can make decisions in the configuration file itself, you usually don't need to make multiple versions of the same file in distinct directories. My Emacs configuration, for instance, has just one version for all six or so varieties of machines I use regularly -- and some of them are running Emacs 20, which is many years old!

Sometimes you do have to do some splitting. The xmodmaprc file, for instance, sets up mapping between keycodes and key names (among many other things it can do). I keep a version for my home machine in ~/config/heechee/xmodmaprc and another version in ~/config/sun/xmodmaprc for all the Sun machines I use. There is no logic in the xmodmaprc format, so splitting it is the only recourse. I did, however, create just one xmodmaprc file for all the Sun machines, because all of them have the same keyboard model.

The crontab file (which I keep in ~/.crontab and periodically reload into crontab) is an extreme example of a configuration file that needs to be specific to each machine. The crontab from my home machine would be inappropriate for any other machine, and there is no logic in the standard crontab format to choose between cron jobs based on anything other than time.

The bottom line is that you should figure out if multiple versions of a configuration file are needed, and then decide the best way to organize those multiple versions. Your goal should be to have a consistent environment, not to spend hours upon hours writing and maintaining configuration files. I hope the techniques explained in this article prove useful in your search for configuration Nirvana.

Conclusion


I hope you found this article interesting and useful. Take what you can from it -- I've spent years perfecting my setup, and it should serve you in good stead.

Convert to this scheme a little at a time, don't get overwhelmed. You can easily spend days rewriting your configurations -- so do it gradually and you'll enjoy the process.

The greatest benefit you'll see is the automatic update function. On any of your machines, you can commit a file and it will show up everywhere else the next time maintain.pl is run! Even if you disagree with the directory structure, think about the power of the automatic updates and how they can be useful to you.

The second benefit you get is configuration archiving. Every version of your configurations will be in the revision control system! If you make a mistake, you can go back to an earlier version. If you lose a whole machine to, say, disk failure -- you can recover all the time-consuming configuration files you wrote for it in minutes.

Don't be tempted to convert everything to this scheme. Convert just the things you want to keep or reuse. Binary files don't work well with CVS -- at the very least, you won't have the diff capability that CVS provides for text files. Also, CVS has trouble with renaming directories, although it's certainly possible if you also rename the directory in the repository.

Finally, keep good backups of your CVSROOT repository, wherever it is. I hope you never need them.

Resources

About the author
Teodor Zlatanov graduated with an M.S. in computer engineering from Boston University in 1999. He has worked as a programmer since 1992, using Perl, Java™, C, and C++. His interests are in open source work, Perl, text parsing, three-tier client-server database architectures, and UNIX system administration. Suggestions and corrections are welcome; contact Ted at [email protected]

Slashdot Linux Distros with CVS-RCS for Config Files

Just do it (Score:1)
by choi (189590) on Monday July 19, @07:47PM (#9743061)
nothing prevents you from just installing cvs and importing/checking out your config directories. i think it's really not that much work to justify a distro on its own.
Do it yourself (Score:1)
by Matt Perry (793115) c o m> on Monday July 19, @07:51PM (#9743096)
Why not just do it yourself? I keep all of my config files in CVS on my Debian and RedHat boxes. It's pretty easy to set things up to do this.
[ Reply to This ]
Gentoo does this. (Score:4, Informative)
by djcapelis (587616) on Monday July 19, @07:54PM (#9743121)
(http://new.se.foml.inodetech.com/)
Gentoo offers several choices in managing the configuration files in /etc, one of these options is the dispatch-conf script which keeps all changes in RCS. This is mostly for updating... so it's not everything, but it's definately a strong start and you could likely use the same system to keep track of your own modifications.
[ Reply to This ]
Nothing is stopping you from doing this. (Score:5, Informative)
by Feztaa (633745) on Monday July 19, @08:02PM (#9743198)
(http://rbpark.ath.cx/ | Last Journal: Wednesday June 30, @04:56AM)
Just go into your /etc/, do a 'mkdir RCS', and then start checking your config files in and out of RCS to edit them. There's no code anywhere in linux that says 'if there's a directory I don't recognize, then crash spectacularly', so just adding the RCS directory itself isn't going to adversely affect anything.

That's actually a really good idea, too, I'm not sure why I never thought of it myself...

[ Reply to This ]
works for my user accounts (Score:5, Interesting)
by x00101010x (631764) on Monday July 19, @08:04PM (#9743224)
(http://slashdot.org/~x00101010x/ | Last Journal: Monday February 16, @04:44AM)
I keep my entire home directory in a Subversion repository. Works great for linux and my windows boxes. Firefox and thunderbird user directories are compatible across platforms.
I just add 'svn up' to my login script and 'svn ci --message "%HOST%@%TIME%%DATE%"' to my logout script.
No reason it shouldn't work for a whole system with an initial 'svn up' somewhere in rc.local and periodic updates in a chron job. Just do a commit whenever you change things on your template system and 5 minutes later it'll be on all your boxen.

There was a slashdot article about putting a home directory under version control a few months ago from which I got the idea, too lazy to find the link at the moment though.

[ Reply to This ]
BitKeeper (Score:2)
by twoflower (24166) on Monday July 19, @08:36PM (#9743457)
Larry McVoy designed BitKeeper with the specific aim of doing this. I believe they also offer special single-user free licenses for this; you may want to check the BitKeeper documentation to see if there are any Linux distributions who actually took him up on this.
[ Reply to This ]
Most distros have CVS installed, right? (Score:1)
by Neil Blender (555885) on Monday July 19, @08:41PM (#9743490)
so:

[user@localhost]# su
password:
[root@localhost]# cd /
[root@localhost]# cvs import . -m 'my linux distro' mydistro username start

[ Reply to This ]
Yes, Gentoo... (Score:2, Informative)
by andrewdk (760436) on Monday July 19, @08:49PM (#9743568)
(http://turbogfx.homelinux.org/)
YEs, Gentoo can do this. Just emerge rcs, make an /etc/config-archive dir, setup /etc/dispatch-conf.conf, and just do dispatch-conf in place of etc-update.
[ Reply to This ]
An old idea for modern times... (Score:3, Insightful)
by Deagol (323173) on Monday July 19, @11:24PM (#9744742)
(http://slashdot.org/)
I think it was OpenVMS (fuzzy memories of a freshman computer class) that had version control built into the filesystem. I'm amazed that this hasn't been introduced into the more popular filesystem(s) yet. I've wished for it on many occasions.

Or am I just being impatient? Will Reiser4 provide this capability?

[ Reply to This ]
FreeBSD (Score:2, Interesting)
by Scythe0r (197724) on Tuesday July 20, @12:14AM (#9745206)
You should really check out a utility for FreeBSD called mergemaster. You run it after rebuilding/upgrading your system and it compares the latest "vanilla" system configuration files to what you've got.

You can choose to overwrite your file, keep your file or merge the two together. I like to think of it as the ultimate choice in system housekeeping.

[ Reply to This ]
  • Re:FreeBSD by Rysc (Score:2) Tuesday July 20, @06:38AM
  • 1 reply beneath your current threshold.
System Restore (Score:2)
by yotaku (26455) on Tuesday July 20, @01:51AM (#9745748)
(http://yotaku.homeip.net/)
As many people have pointed out having versioning on the config of a system is hardly a new idea. If you think about what might happen if you try to make this idea simple and easy to use it might end up being something like System Restore for Windows, which stores versions before updates, and if you're smart you make a check point before installing any questionable software or drivers. And then allows you to roll back if something goes wrong and the uninstall doesn't fix it.
[ Reply to This ]
changetrack (Score:1)
by Christopher Cashell (2517) on Tuesday July 20, @04:19AM (#9746397)
(http://www.zyp.org/ | Last Journal: Saturday August 18, @01:39AM)
sudo apt-get install changetrack
For non-Debian users, download changetrack [sourceforge.net] from SourceForge.

changetrack uses RCS as it's backend, not CVS (support for CVS is on the Todo list), but the end result is the same. It is specifically intended for tracking system files like those in /etc.
[ Reply to This ]
dispatch-conf (Score:1)
by trickycamel (696375) on Tuesday July 20, @09:21AM (#9747791)
Gentoo does this for your files in /etc. Use dispatch-conf and forget about etc-update. You can set it to use RCS, so no more overwrites of your configs.
[ Reply to This ]
RCS and vim (Score:1)
by wolf31o2 (778801) on Tuesday July 20, @10:43AM (#9748872)
(http://www.gentoo.org/)
At work, we have a simple wrapper for vim that does all of the RCS stuff for us, like checking in and checking out files. We use it on all of our production servers, as it gives use nice revision control over our files.
#!/bin/bash

ORIGVI=rcsvi

case $1 in
-r[0-9]*) VERSION=$1; shift ;;
esac

[ $# -eq 1 ] || { echo usage: vi [-rrev] filename >&2; exit 1; }
DIR=`dirname $1`
FILE=`basename $1`

### let vi handle error conditions
cd $DIR || exec $ORIGVI $1
[ -d $FILE ] && exec $ORIGVI $FILE

### skip certain directories
{ [ -r $HOME/.rcsvirc ] && . $HOME/.rcsvirc; } ||
{ [ -r /etc/rcsvirc ] && . /etc/rcsvirc; } ||
EXCLUDE="/tmp | /tmp/* | /etc/skel | /etc/skel/* | /home | /home/* | /usr/home | /usr/home/*"
[ -n "$EXCLUDE" ] && eval "case $PWD in $EXCLUDE) exec $ORIGVI $FILE ;; esac"

### create RCS directory if not exist
[ -d RCS ] || { mkdir RCS || exit $?; }

### check $FILE for existence, break possible lock or exit, check in
[ -e $FILE ] && { [ -e RCS/$FILE,v ] && { rcs -l $FILE || exit 1; }
ci -q -l $FILE </dev/null; }
[ -n "$VERSION" ] && { co $VERSION $FILE; chmod u+w $FILE; }

### edit $FILE
$ORIGVI $FILE

### check in $FILE
ci -u $FILE

# EOF

[ Reply to This ]
cfengine (Score:2, Informative)
by bandix (184495) <<ten.knupkeeg> <ta> <xidnab>> on Tuesday July 20, @06:36PM (#9754240)
(http://www.geekpunk.net/)
You'll spend years fooling around with RCS and CVS for configuration versioning before realizing that what you really need is cfengine. CVS or svn for source code, cfengine for configuration. Cut to the chase:

http://www.cfengine.org/

freshmeat.net Project details for cvs2cl.pl

cvs2cl.pl generates GNU-style ChangeLogs for a CVS working copy. There are many options to control the output.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

CVS--Concurrent Versions System -- a good description of CVS with some exposure of internals.

FrontPage - The CVSNT Wiki

CVS BUBBLES the most interesting subpage for CVS. See also Related tools

Cameron Laird's personal index to publicly-accessible CVS re - Quick guide to open-source CVS repositories

CVS page at CERN - material related to CVS

CVS Version Control for Web Site Projects - use of cvs version control for web development

cvsweb sean - May 22nd 1998, 06:21 EST http://lemming.stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi

cvsweb is a visual (www) interface to explore a cvs repository. This is an enhanced
cvsweb developed by Henner Zeller. Enhancements include recognition and display
of popular mime-types, visual, color-coded, side by side diffs of changes and the
ability sort the file display and to hide old files from view. One living example of
the enhanced cvsweb is the KDE cvsweb

Pcl-CVS - The Emacs Front-End to CVS.

Cyclic software - Former maintainer of CVS ! http://www.cyclic.com/tkcvs/. See also SlashdotCyclic discontinues offering CVS support contracts

Matra Internetworks CVS Information Page

The CVS Continuity Project

ComponentSoftware RCS (CS-RCS)

cm-guide.html

Presentations

Introduction to CVS

Reference

Version Management with CVS by Per Cederqvist et al is the "official" manual for CVS. Commonly known as "the Cederqvist," the manual covers repositories, branches, and file maintenance, and includes reference material for both CVS users and CVS repository administrators. This manual is available in several formats from this page. If you need others, the texinfo source file for the manual can be found in the `doc' directory of the CVS source distribution.


You will need to have the Adobe Acrobat Reader installed on your system in order to view the PDF documents offered on this page. Luckily, Adobe offers their Reader for free on their webpage.

MarkD's Guide to CVS

I haven't found any documentation for using CVS from a web nerd (a.k.a. ArsDigita) point of view. Since I've used revision control for the last 10 years, and CVS during my tour of duty at AOL, I figured I'd regurgitate what I know.

Table of Contents

The complete Open Source Development with CVS, 3rd Edition is available under the GNU General Public License:

Thanks to Jan Wolff for transforming the original PDFs from Paraglyph Press into this more useable form. Jan consolidated Paraglyph's multiple files into a single file, and remove the cutting marks from around the page edges to make it more readable.

You can order a copy of the book from Paraglyph through their distributor, O'Reilly:

NOTE: There is an error in the copyright notice printed in the version of the book sold in bookstores. The entire book is available under the GNU General Public License - see here for details.

The electronic copy of the 3rd edition comes directly from the publisher's PDF files. Due to certain complexities of the publishing process, there are no source files from which the PDFs were generated. Therefore, I simply distribute the PDFs as masters; they serve as both source and binary format. Sorry for the inconvenience. If you have tools able to convert PDF to a more editable format, please contact me at [email protected]. I'd like to offer the book in editable form, only technical difficulties prevent it.

There are also some translations available, though as far as I know these are of the 1st edition:

Errata:
If you have a copy of the first printing, you may wish to consult the list of known errors. This list applies only to the treeware, and only for the first printing. The second printing has corrected these bugs. The second and third editions may contain other errors; I am slowly combing through my mailbox to see if anyone has mentioned any.

Alternate Formats for the 1st Edition

Because I have source files for the 1st edition of the book, I am able to offer it in several formats besides PDF:

Please email [email protected] regarding problems with this website.

Other Resources

Please suggest other CVS resources for this list by emailing [email protected].

Open Source Development With CVS : Learn How to Work With Open Source Software
by Karl Franz Fogel

Our Price: $31.99
You Save: $8.00 (20%)
Paperback - 400 pages (November 1999)
The Coriolis Group; ISBN: 1576104907 ; Dimensions (in inches): 0.96 x 9.24 x 7.42
Amazon.com Sales Rank: 4,776
Avg. Customer Review: 5 out of 5 stars

available online. (The paper version has additional non-free material.)

CVS BUBBLES the most interesting subpage for CVS. See also Related tools

Cameron Laird's personal index to publicly-accessible CVS re - Quick guide to open-source CVS repositories

CVS page at CERN - material related to CVS

CVS Version Control for Web Site Projects - use of cvs version control for web development

cvsweb sean - May 22nd 1998, 06:21 EST http://lemming.stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi

cvsweb is a visual (www) interface to explore a cvs repository. This is an enhanced
cvsweb developed by Henner Zeller. Enhancements include recognition and display
of popular mime-types, visual, color-coded, side by side diffs of changes and the
ability sort the file display and to hide old files from view. One living example of
the enhanced cvsweb is the KDE cvsweb

Pcl-CVS - The Emacs Front-End to CVS.

Cyclic software - Former maintainer of CVS ! http://www.cyclic.com/tkcvs/. See also SlashdotCyclic discontinues offering CVS support contracts

MacCVS.org - provide free and open CVS client software for Mac OS ...

Matra Internetworks CVS Information Page

The CVS Continuity Project

ComponentSoftware RCS (CS-RCS)

cm-guide.html

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019