The Five-Minute RCS Tutorial - Automating System Administration with Perlby 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.
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.
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
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
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.
-uis 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 -l services
-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
<revision number>to check out an older revision of a file
-pto 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 (
check-in process stores any changes made to this file in a space-efficient
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
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
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.
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.
co example, can also take a
number> flag to allow you to compare two past
Table E.1, “Common RCS operations” lists some common RCS operations and their command lines.
Table E.1. Common RCS operations
Initial check-in of file (leaving file active in filesystem)
Check out with lock
Check in and unlock (leaving file active in filesystem)
Display version x.y of a file
Undo to version x.y (overwrites file active in filesystem with the specified revision)
Diff file active in filesystem and last revision
Diff versions x.y and x.z
View log of check-ins
Break an RCS lock held by another person on a file
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.
ftp://ftp.gnu.org/pub/gnu/rcs 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).
http://cygwin.com 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 http://www.cs.purdue.edu/homes/trinkle/RCS.
Applying RCS and SCCS: From Source Control to Project Control, by Don Bolinger and Tan Bronson (O’Reilly), is an excellent RCS reference.
http://www.nongnu.org/cvs and http://subversion.tigris.org 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 http://en.wikipedia.org/wiki/Distributed_Version_Control_System.
If you enjoyed this excerpt, buy a copy of Automating System Administration with Perl, Second Edition .