The Five-Minute RCS Tutorial - Automating System Administration with Perl

by David N. Blank-Edelman

This quick tutorial will teach you everything you need to know to use the Revision Control System (RCS) for system administration. RCS is useful for applying version control to all of your system files. It has considerably more functionality than we’ll discuss here, so be sure to take a look at the manual pages and the references at the end of this appendix if you plan to use it heavily. You may also be wondering why we’re bothering with RCS when more modern systems, such as Git and Subversion, exist. That’s a good question, and I’ll address it at the end of the tutorial. In the meantime, though, let’s get the RCS basics down; they’ll help with the explanation later.

System Administration with Perl, Second Edition book cover

This excerpt is from Automating System Administration with Perl, Second Edition . Thoroughly updated and expanded in its second edition to cover the latest operating systems, technologies, and Perl modules, Automating System Administration with Perl will help you perform your job with less effort. The second edition not only offers you the right tools for your job, but also suggests the best way to approach particular problems and securely automate pressing tasks.

buy button

RCS functions like a car rental agency. Only one person at a time can actually rent a particular car and drive it off the lot. The agency can only rent out a new car after adding it to its pool. Customers can browse the list of cars (and their features) at any time, but if two people want to rent the same car, the second person must wait for the car to be returned to the lot. Finally, car rental agencies inspect cars very carefully after they have been returned and record any changes that took place during the rental. All of these properties hold true for RCS as well.

In RCS, a file is like a car. If you wish to keep track of a file using RCS (i.e., add it to the rental lot), you must “check it in” for the first time:

$ ci -u inetd.conf

ci stands for “check in,” and the -u tells RCS to leave inetd.conf in place during the check-in. When a file is checked in (i.e., made available for rental), RCS does one of two things to remind the user that the file is under RCS’s control:

  1. Deletes the original file, leaving only the RCS archive file behind. It sometimes distresses new users of RCS when the file seems to disappear after being checked in, but in fact the data has just been squirreled away in its archive file. This archive file is usually called filename,v and is kept either in the same directory as the original file or in a subdirectory called RCS (if the user creates it). You must protect the RCS directory and archive file (using filesystem permissions) at least as strongly as the original file.

  2. If -u is used (as in our earlier command), it checks the file out again, leaving the permissions on the file set to “read-only.”

To modify a file under RCS’s control (i.e., rent a car), you first need to “check out” (co) that file:

$ co -l services

The -l switch tells RCS to “strictly lock” services (i.e., do not allow any other user to check out services at the same time). This lock is respected only by RCS; the file is not actually locked using filesystem capabilities (ACLs, attributes, etc.). Other switches that are commonly used with co include:

  • -r <revision number> to check out an older revision of a file

  • -p to print a past revision to the screen without actually checking it out

Once you are done modifying a file, you need to check it back in using the same command you used to put the file under RCS’s control (ci -u filename). The check-in process stores any changes made to this file in a space-efficient manner.

Each time a file that has been modified is checked in, it is given a new revision number. At check-in time, RCS will prompt you for a comment to be placed in the change log it automatically keeps for each file. This log and the listing of the current person who has checked out a file can be viewed using rlog filename.

If someone neglects to check her changes to a particular file back into RCS (perhaps having gone home for the day) and you have a real need to change the file yourself, you can break that person’s lock using rcs -u filename. This command will prompt for a break-lock message that is mailed to the person who owns the lock.

After breaking the lock, you should check to see how the current copy differs from the RCS archive revision. rcsdiff filename will show you this information. If you wish to preserve these changes, check the file in (with an appropriate change-log comment), and then check it back out again before working on it. rcsdiff, like co example, can also take a -r <revision number> flag to allow you to compare two past revisions.

Table E.1, “Common RCS operations” lists some common RCS operations and their command lines.

Table E.1. Common RCS operations

RCS operation

Command line

Initial check-in of file (leaving file active in filesystem)

ci -u filename

Check out with lock

co -l filename

Check in and unlock (leaving file active in filesystem)

ci -u filename

Display version x.y of a file

co -px.y filename

Undo to version x.y (overwrites file active in filesystem with the specified revision)

co -rx.y filename

Diff file active in filesystem and last revision

rcsdiff filename

Diff versions x.y and x.z

rcsdiff -rx.y -rx.z filename

View log of check-ins

rlog filename

Break an RCS lock held by another person on a file

rcs -u filename

Believe it or not, this is really all you need to get started using RCS. Once you start using it for system administration, you’ll find it pays off handsomely.

References for More Information has the latest source code for the RCS package (though it is available through most standard packaging mechanisms if it doesn’t ship with your OS). is a source for an RCS package (and many, many other Unix-born programs). If you’d like to install RCS without requiring the entire Cygwin environment, there is a version available at

Applying RCS and SCCS: From Source Control to Project Control, by Don Bolinger and Tan Bronson (O’Reilly), is an excellent RCS reference. and are the places to go if you find you need features not provided in RCS. The next step up is either the Concurrent Versions System (CVS) or Subversion (SVN).

The next step up from CVS and SVN is the crop of relatively new distributed version control systems, such as git, mercurial, bazaar, and darcs. For more info, check out the article at

If you enjoyed this excerpt, buy a copy of Automating System Administration with Perl, Second Edition .