RCS stands for "Revision Control System". It is a system provided by FSF, the Free Software Foundation, for keeping track of revisions to text files. Programmers use rcs (or sccs, a similar system) for controlling revisions to program text (source code). This is extremely important for code being worked on by a team of programmers but is also very useful for the individual programmer. When you are developing a program you should check in your changes to rcs freqently: whenever you begin a new development of the program, and also at least once a day or often enough that you don't mind losing all your recent work should something go wrong. When something goes wrong (for example you accidentally delete your file, or you horribly mangle the development of some method) you can revert to a previous version of the file by checking it out of rcs. You can also compare two versions of the file, for example your current version and the version you most recently checked in, by using rcsdiff.

Suppose you are developing a file called foo.java. It's convenient to store the rcs files in a separate directory, so type

mkdir RCS

to create an RCS subdirectory of the directory where you are developing foo.java. The rcs programs look first in a subdirectory RCS (upper case) for rcs files. You can make an RCS subdirectory in each directory where you have documents whose changes you want to keep track of. Now type

rcs  -i   foo.java

to begin storing revisions of foo.java. Next type

ci  -l   foo.java

to check in ("ci" stands for "check in") the current version of foo.java. You will be prompted to add a comment describing what foo.java is about. Your comments can be in several lines.

Put a single '.' on one comment line to tell the program you are done adding comments. The –l flag puts a lock on the file (which you really only care about in multi-developer situations) and keeps a writeable copy of the file in your working directory. If you omit the -l flag to ci the program will remove the copy of foo.c from the directory. You could also use a –u flag instead of –l, to keep a non-writable copy of the file in your working directory. Now type

ls  -l   foo.java

and you should see that foo.java is still writable

Now you can continue to work on your file, doing more writing. Periodically type

ci   -l  foo.java

add your comments on the latest changes and then continue working on the file.

Before checking in your changes you can type

rcsdiff   foo.java

to see what you have changed since you last checked the file in. It’s a good idea to check in your changes after every working session, more often if you make major changes to a file.

If something bad happens to foo.java while you are working on it you can recover your last version by typing

co  -l   foo.java

This checks out ("co" stands for "check out") a writable copy of foo.java, locking it so nobody else can check in a copy of foo.java before you. This feature is required for multi-developer situations.

You must save your work often enough to avoid losing a lot of work. You can also retrieve a given earlier version, for example revision 1.7, by

co  -l  -r1.7   foo.java

If you want to learn more, try the man pages. For example you might try

man   rcsintro

for a more detailed introduction to rcs. Try

man   diff

for information on diff, whose format rcsdiff uses. For yet more info, try "man rcs", "man ci" and "man co", once you have been using rcs for a while.

Colin Godfrey

Aug 1997

modified Feb 1998