Revision Control Source code tracking in the Unix environment
From "Migration",  Access to Wang, May 1995
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

The increasing complexity of software development - along with the quickening pace at which development is carried out - have combined to make source code tracking systems necessary for all but the smallest shops.

Unix systems usually come with such a system, typically either Source Code Control System (SCCS) or Revision Control System (RCS). Both control access to source files, check out a file to a user for modification, record changes to the file when it is checked in and log change activities. These utilities meet the basic requirements identified for the VS-based system I described last month (See "Source Code Tracking on the VS, Access to Wang, April 1995).

In addition, these systems offer extra benefits:

• They control access to source files more directly, using Unix file permissions to enforce the checkout and checkin processes.

• They extract any prior version of the source.

• .They compare any previous version of the file to any other version, past or present.

• They create script files that will bring any version of the source to any other version (e.g. diff listings).

• They log comments on each change.

• They control release levels (version numbering) and configuration types (production version, experimental, bug fix, etc.).

• They automatically insert fields within the source file that identify the version number, date of change, user performing the change and other information.

• They provide a means of identifying object versions and the corresponding source versions that produced them.

SCCS and RCS have similar capabilities, so I will concentrate on the features of RCS and compare them with SCCS commands later in the article.

Using RCS

RCS was written by Walter F. Tichy of Purdue University in the late 1970s and placed in the public domain. Like SCCS and most other source control systems, it works by setting up an archive for the original source file, including lists of changes made to that file and logs of those changes.

To set up a file for RCS control, use the ci (check in) command to create the RCS archive.

For example, type ci myfile.cob to create an archive for the source file myfile.cob; this archive will be named .Imyfile.cob,v (read: file name myfile.cob,v in the current directory).

Archive files can also he located in other directories, either through explicit naming via the ci command or by establishing a subdirectory named RCS in the source directory. In the latter case, the archive path and name would be .IRCS/ myfile.cob,v (e.g. file name myfile.cob,v in subdirectory RCS). I use the RCS subdirectory approach to hide the archives, limiting the number of files displayed in the source directory to those presently in use.

Whenever the ci command is used, it will prompt for a description of the change and record a version number. RCS assumes that new files will have the version number 1.l and that subsequent version numbers will be incremented in tenths; for example, the first revision to myfile.cob would be version 1.2. Version numbers can also be set explicitly through additional arguments to the ci command - more on that later.

Once a file is established as an RCS archive, you must use the co (check out) command to retrieve a copy of that file. Without any arguments, RCS will deliver a read - only copy of the latest version of the file; for example, co myfile.cob would return a copy of that file from the archive with file permissions that would not allow modification.

Adding the -l (lock) argument to the command string (co -l myfile.cob) causes RCS to return the same version but with file permissions set for exclusive modification by that user. RCS also records the user ID and the fact that the file is checked out.

Once a file is checked out and locked, other users will receive a warning that the file is under modification when they attempt to check out the same file.

Once modifications are complete, the new source file can be checked back into the archive, releasing the lock, logging the differences between versions of the file and creating a new version.

Again, the ci command is used (ci myfile.cob), and RCS will prompt for a description of the change. By default, RCS will remove the source file after performing its logging and differences processing; add the -u option to unlock the file but leave a copy for review and compilation.

Inserting Keywords In Source And Object

Most revision control systems also provide a means of adding logging information to the source versions, usually at the time the file is checked in and a new version number is logged.

Small keyword tokens inserted into the source text are replaced with expanded information by RCS. Possible keywords include author, date of revision, full path, comments by the programmer, revision number and state (production, experimental, etc.).

Using RCS keywords is simple: place the keyword within the source file, preferably in a comment. A COBOL example might look like:

007500* RCS header follows 007600* $Header$ 007700

When checked back in, RCS would replace the string $Header$ with something like:

007500* RCS headar follows 007600* $Header: nyfile.cob,v 1.3 95/01/01 17:05:04 dsb Exp $ 007700

The actual values expanded by these keywords vary between versions of RCS; test your system to determine the exact formatting.

If the keyword values are expanded into the contents of a variable shown within the object file, the ident command may be used to show the source version used to produce that object.

In our COBOL examples, a variable in WORKING-STORAGE would be established with an initial value of $Header$. When the source file is archived, the expanded information would become a part of the object file as a literal value.

Caution: This technique may not work for interpretive compilers (AcuCOBOL, etc.), and the expanded length may exceed the column area allowed for program code in some compilers.

Advanced Uses Of RCS

Besides the commands mentioned above, RCS also includes other commands for advanced purposes. These include:

• rcsdiff: Compares two past versions or a past version with the current version. A diff listing is produced, similar to the listing on page 11; this may be used as a script for the ed editor to perform revisions on a source file.

• rcsintro: Not a command but a Unix manual page that describes most of the functionality of RCS.

• rcsmerge: Merges two versions of a source file into an RCS archive, warning of overlapping differences in the two new versions. This command is useful when more than one change is occurring to a program at the same time.

• rlog: Lists information on the contents of an RCS archive, including revision numbers, comments and dates.

In addition, the ci and co commands come with several advanced options you may wish to explore. Consult your system's manual for details.

Other Source Control Systems

As mentioned above, some Unix systems substitute SCCS for RCS as their source control system. Like RCS, SCCS stores original source files and their changes in a single archive file and uses commands to check files in and out. The primary differences lie in syntax:

• Unlike RCS, the initial setup of source files in the SCCS system is not the same as checking in a file; instead, you must set up the archive with the admin command.

• The co and ci commands are replaced by get and delta, respectively.

• SCCS has more options for version branching, the ability to maintain versions based on multiple original versions. (This is primarily of interest to those developing commercial software, since it allows minor bug-fix releases between major release levels.)

• SCCS can enforce the use of accounting codes that allow program changes to be applied to work orders, departments or any other coding scheme.

• Command-line syntax for SCCS is less intuitive, requiring careful use or scripted procedures for best results.

Commercial versions of both systems are also available from system software dealers. These products offer enhanced accounting and control capabilities for more complex needs. Some systems are able to manage binary files (object modules, Visual Basic Custom Controls, etc.) or maintain versions for multiple platforms (OS/2, Unix, Windows, NT, and so on). Consult vendors for more information.

Summary: Vs Source Control

As you can see, the RCS and other source control systems have functionality beyond that described for the VS-based system covered last month. Some of these additional functions include better protection for the source files and more comparison and logging functionality. Some of these capabilities could be added to a VS-based system.

Here's my wish list for better VS source control:

• Protect source files better by removing direct access to them, forcing use of the checkout facility. Where appropriate, remove programmer access rights to source, instead granting access through security rights assigned to the source control programs.

• Improve the integration of the editor and linker environments, adding version numbers and comments to the existing link fields. Use SHOVERZN (Show Version) or equivalent tools to match object files to the source versions that produced them.

• Add a source code preprocessor that would insert version and other logging data into the source file as versions were struck, similar to the keyword functionality of RCS and SCCS.

In short, the capabilities of the VS for source control are there, but it is up to you to make the tools. Source code change control requires some effort but can provide cheap insurance against accidental loss or mistakes in design.