RCS Summary

This page summarizes RCS (briefly) so that it can be used on both the Duke CS system (running NFS) and the acpub system (running AFS). The only differences in the systems occur in setting up the directory structure for a group to work with. The RCS commands are the same. For full information see man pages for the relevant commands, to get started you can try man rcsintro which provides a very brief introduction as well as pointers to other commands illustrated below.

(Information for this summary comes forom the O'Reilly publication Applying RCS and SCCS, class notes by Syam Gadde for CPS 108, Fall 1996, and man pages.)

Directory Structure

For a group to use RCS an RCS directory must be created. The picture below shows an RCS directory for a group project named oodle for a three-person group where the login ids for the group members are peter,paul, and mary.

*

In this diagram peter creates the subdirectory named this RCS as a subdirectory of his oodle directory. The other group members also create oodle subdirectories. Users paul and mary then create symbolic links to the group RCS subdirectory (the links are created in their respective oodle subdirectories.

ln -s ~peter/oodle/RCS RCS

The group will then need to make the RCS subdirectory writeable by each person in the project. This is described below.

Once this is done, each person works in their own oodle subdirectory, checking files into and out from the common RCS subdirectory.

AFS (acpub) Access Control Lists

On the acpub system running AFS, individual users can create groups. Use the pts command to do this. To create a group (done by peter, for example): pts creategroup peter:oodle To add users to the group: pts adduser paul peter:oodle pts adduser mary peter:oodle Now the RCS directory can be made writeable by the group, peter does this since he owns the directory. fs setacl RCS peter:oodle write Now files can be checked in or out as described below.

NFS (duke.cs) Permissions

Under NFS (the Duke CS file system) individual users cannot set up groups. The RCS subdirectory must be readable/writeable by the world. The mechanism below shows how to make this very secure so that only project members can actually read/write the RCS directory.

Each group member creates an oodle subdirectory accessible only to them. Permissions are set using chmod as follows:

chmod 700 oodle Then one group member, say peter, creates a directory named protected with permissions 711 (group and user can access the directory) chmod 711 protected Then, a subdirectory of protected is created, the name is only known to group members. In the diagram below this name is xyzsecret. The permissions on this directory are also 711. Finally, an RCS subdirectory of xyzsecret is created with world read/write permissions 777 as shown.

*

Each group member creates a symbolic link to ~peter/protected/xyzsecret/RCS from their oodle subdirectory. The RCS directory is accessible since the search/access (x) bit is set on subdirectories protected and xyzsecret. Since there is no read permission set on protected, no on (except peter) can effectively use the ls command to see the names of the files.

Using RCS

A brief introduction to RCS is given here. More information will be added soon, the information below is enough to get started.

Every RCS file is stored in the RCS directory, but worked on in the parent directory (oodle in the example above). The file foo.cc is stored in the RCS directory as foo.cc,v.

To begin, a file is checked in using the command ci. To work with a file it is checked out using the command co.

Check In: ci

Initially a file is checked in using ci: ci foo.cc You'll be prompted for a message when doing this. Later, after editing a file, you'll need to check it in again to update the file by storing a revised version. A file can be checked in using (at least) three different mechanisms:

Check Out: co

To check out a file to work on use the command co: co -l foo.cc This checks the file out with a lock so that it can be edited. If it's locked, no one else can check it out for editing. Without the -l option the file is checked out read only so that it can be viewed, but not changed.

Versions

The commands ci and co as shown above always work on the most recent version. Specific versions can be checked out using a number: co -l2.2 foo.cc co -r2.2 foo.cc The first checks out version 1.2 of foo.cc with a lock, the second doesn't acquire a lock. Version control has other options including branches and new lines, e.g., 2.1, 2.2, 1.3.1, etc.

RCS commands

Sometimes you want to remove a file without checking it in when you have lock. The command rcs -u foo.cc will do this. You can also use this command to remove a lock that someone else has set (don't do this unless someone inadvertently leaves a file checked out and locked). If you remove someone else's lock an email message is sent. Man pages show more rcs options (and ci and co, ...).

RCS Keywords

You can include RCS keywords in source (and object) code so that the revision number, author, date, etc. is always shown in code (and in object files). A keyword is typed with case matching exactly as shown below between two dollar signs $$, e.g., $Date$. When a file is checked out, the keyword is replaced by its value, e.g., "January 22, 1997". Keywords are typically put in comments as shown below. #include <iostream.h> // Demo program for RCS // $Author$ // $Date$ // $Id$ // int main() { cout << "Hello World" << endl; } When the file is checked out (for the first time) the source is as follows: #include <iostream.h> // Demo program for RCS // $Author: ola $ // $Date: 1997/01/20 22:58:41 $ // $Id: foo.cc,v 1.1 1997/01/20 22:58:41 ola Exp $ // int main() { cout << "Hello World" << endl; } To include RCS information in object files, create a dummy string variable in your source code that will generate a string in the compiled code. static const char rcsid[] = $Id$;
ola@cs.duke.edu
Last modified: Tue Jan 21 15:35:50 EST