Linux Unleashed, Third Edition:Source Code Control
-->
Previous
Table of Contents
Next
Deltas
The set of changes that RCS records for an RCS file is referred to as a delta. The version number has two forms. The first form contains a release number and a level number. The release number is normally used to reflect a significant change to the code in the file. When you first create an RCS file, it is given a default release of 1 and level of 1 (1.1). RCS automatically assigns incrementally higher integers for the level number within a release (for example, 1.1, 1.2, 1.3, and so on). RCS enables you to override this automatic incrementing whenever you want to upgrade the version to a new release.
The second form of the version number also has the release and level components, but adds a branch number followed by a sequence number. You might use this form if you were developing a program for a client that required bug fixes, but you don’t want to place these fixes in the next “official” version. Although the next version may include these fixes anyway, you may be in the process of adding features that would delay its release. For this reason, you would add a branch to your RCS file for this other development stream, which would then progress with sequence increments. For example, imagine that you have a planned development stream of 3.1, 3.2, 3.3, 3.4, and so on. You realize that you need to introduce a bug fix stream at 3.3, which will not include the functionality proposed for 3.4. This bug fix stream would have a numbering sequence of 3.3.1.1, 3.3.1.2, 3.3.1.3, and so on.
Tip: As a matter of good development practice, each level or sequence should represent a complete set of changes. That implies that the code in each version is tested to be free of any obvious bugs. You shouldn’t jump from version 2.00 to 3.00, for example, just because you fixed a few bugs in 2.00. Usually, major version increases are related to additional features, not maintenance releases.
Note: Is any code ever completely bug-free? This certainly isn’t the case for complex programs in which bugs may become apparent only when code is integrated from different developers. Your aim is to make at least your own part of the world bug-free. While we’ll never achieve bug-free programs, we can minimize the potential bugs and isolate the few that remain much more easily.
Creating an RCS file
Let’s assume that you have the following file of C code, called finest.c:
/* A little something for RCS */
#include <stdio.h>
main()
{
printf(“Programming at its finest…\n”);
}
The first step in creating an RCS file is to make an RCS directory:
$ mkdir RCS
This is where your RCS files are maintained. You can then check a file into RCS by issuing the ci (check-in) command. Using your trusty finest.c program, enter the fol-lowing:
$ ci finest.c
This operation prompts for comments and then creates a file in the RCS directory called finest.c,v, which contains all the deltas on your file. After this, RCS transfers the contents of the original file and denotes it as revision 1.1. Anytime that you check in a file, RCS removes the working copy from the RCS directory.
Retrieving an RCS File
To retrieve a copy of your file, use the co (check-out) command. If you use this command without any parameters, RCS gives you a read-only version of the file, which you can’t edit. You need to use the -l option in order to obtain a version of the file that you can edit.
$ co -l finest.c
Whenever you finish making changes to the file, you can check it back in using ci. RCS prompts for text that is entered as a log of the changes made. This time the finest.c file is deposited as revision 1.2.
RCS revision numbers consist of release, level, branch, and sequence components. RCS commands typically use the most recent version of a file, unless they are instructed otherwise. For instance, say that the most recent version of finest.c is 2.7. If you want to check in finest.c as release 3, issue the ci command with the -r option, like this:
$ ci -r3 finest.c
This creates a new release of the file as 3.1. You can also start a branch at revision 2.7 by issuing the following:
$ ci -r2.7.1 finest.c
You can remove out-of-date versions with the rcs command and its -o option.
$ rcs -o2.6 finest.c
Using Keywords
RCS lets you enter keywords as part of a file. These keywords contain specific information about such things as revision dates and creator names that can be extracted using the ident command. Keywords are embedded directly into the working copy of a file. When that file is checked in and checked out again, these keywords have values attached to them. The syntax is
$keyword$
which is transformed into
$keyword: value$
Some keywords used by RCS are shown in the following list:
$Author$
The user who checked in a revision
$Date$
The date and time of check-in
$Log$
Accumulated messages that describe the file
Revision$
The revision number
If your finest.c file used the keywords from the previous table, the command
$ ident finest.c
produces output like this:
$Author: pete $
$Date: 95/01/15 23:18:15 $
$Log: finest.c,v $
# Revision 1.2 95/01/15 23:18:15 pete
# Some modifications
#
# Revision 1.1 95/01/15 18:34:09 pete
# The grand opening of finest.c!
#
$Revision: 1.2 $