[Chapter 20] 20.14 RCS Basics

20.14 RCS Basics

rcs	[I've patterned this article after the article on SCCS ( 20.13 ) by Bruce Barnett. This one shows how to do the same things with the Revision Control System, RCS, which is on many systems - and also on the CD-ROM. -JP]

You don't need to ask the system manager to restore files. You can recover any version you want with one command. Here is a simple introduction to RCS.

Create a subdirectory called RCS in the directory where you keep the code or other text files you want to protect.
It's a good idea (but not required) to add the characters $Id$ somewhere in the file you want to place under RCS. Put this in a comment field. That is, use /* $Id$ */ in a C program and # $Id$ in a shell or Perl script.
Place the file under Revision Control. This is done by typing:
```
% 

ci

 

filename
```
The ci (checkin) program will prompt you for a short description of the file. That's it. You're done. There is another command and an option you need to know:
```
% 

co

 

filename


% 

co -l

 

filename
```
The co (checkout) command will get a copy of the file from RCS. The file will be marked read-only. If you want to edit the file, use the co -l command (the option is a lowercase L)-then, when you're done, return the file to the RCS directory with the command ci . When you check in the file, ci asks for a brief description of your changes. These can be very useful, later, to learn the history of revisions and to find a particular revision you might want to recover; the command rlog filename gives that info.

There are only two more commands that you will need to know. If you checked out a file for editing, and later on decided you didn't want to change it, use:

% 

rcs -u

 

filename


% 

rm

 

filename

and if you want a list of all files currently checked out, use:

% 

rlog -L -R RCS/*

(If you don't use RCS often, you may want to store those command lines in aliases or shell functions ( 10.1 ) with names like Checkout , Checkedout , and so on.) That's all there is to it! If you are not using RCS or SCCS, you should. They are the best way to protect yourself and do not require dozens of tapes.

It is much easier to just type:

% 

co -r1.12

 

filename

One command, and version 1.12 is restored. If it's not the right one, restore the version before or after the one you just grabbed. (If you don't want to create a file, you can add the -p option to send the file to standard output. Pipe the co output to another program: a pager, a printer, etc.)

If you are worried that you are keeping 12 versions of the file on the disk, and that this will use up a lot of disk space, don't. RCS stores the differences between versions, not 12 separate copies of the file. It can recover any version of the file.

Suppose you delete a file by accident? Well, if the file is just checked out with a co , it will be retrieved and marked read-only, so deleting the file will cause rm to ask you for confirmation. If you do delete it, you can recover it with another co command. Suppose you check out a file with co -l , because you planned to change it. Well, if this file gets deleted accidentally, you would lose the most recent changes. This is why you should check your files back into RCS frequently - several times a day or even more. Do it whenever you make significant changes to the file, and it would be difficult to remember all of the changes. Making hundreds of changes to a file without checking it back into the system is just begging for trouble.

This brief overview left out a lot of features and helpful information. For example, RCS can:

Merge two or more peoples' work into one with rcsmerge and co -j .
Build a tree of revisions with multiple branches and sub-branches. This lets you make and store multiple independent revisions.
Assign an arbitrary `state' to each revision - for example, alpha , released , stable .
Name each revision, refer to revisions by name instead of number.
Keep a list of users who are allowed to manipulate a particular RCS file.

To find out more, see the RCS manual pages. rcsintro (1) gives a more complete overview; manpages like ci (1) have details on the many other useful features. Finally, O'Reilly & Associates' Applying RCS and SCCS is packed with tips and techniques for using revision control in group projects (where you'll need it even more). Articles 27.10 and 20.15 explain tools for searching RCS files. The script in article 25.5 , rcsmore (and rcsless and rcspg ), makes it easy to read through RCS files.

- JP , BB