Maintaining Source Directories

When using SCCS, it is the history files, and not the working copies, that are the real source files.

Duplicate Source Directories

If you are working on a project and want to create a duplicate set of sources for some private testing or debugging, you can create a symbolic link to the SCCS subdirectory in your private working directory:

$ cd /private/working/cmd.dir
$ ln -s /usr/src/cmd/SCCS SCCS

This enables you to retrieve a private (duplicate) set of working copies, of the source files using:

	sccs get SCCS 

While working in the duplicate directory, you can also check files in and out--just as you could if you were in the original directory.

SCCS and make

SCCS is often used with make(1S) to maintain a software project. make provides for automatic retrieval of source files. (Other versions of make provide special rules that accomplish the same purpose.) It is also possible to retrieve earlier versions of all the source files, and to use make to rebuild earlier versions of the project:

$ mkdir old.release ; cd old.release
$ ln -s ../SCCS SCCS
$ sccs get -c"87/10/01" SCCS
SCCS/s.Makefile: 
1.3 
47
.  .  .  
$ make
.  .  .  

As a general rule, no one should check in source files while a build is in progress. When a project is about to be released, all files should be checked in before a build. This ensures that the sources for a released project are stable.

Keeping SIDs Consistent Across Files

With some care, it is possible to keep the SIDs consistent across sources composed of multiple files. The trick here is to edit all the files at once. The changes can then be made to whatever files are necessary. Check in all the files (even those not changed). This can be done fairly easily by specifying the SCCS subdirectory as the file name argument to both edit and delta:

$ sccs edit SCCS
.  .  .  
$ sccs delta SCCS

With the delta subcommand, you are prompted for comments only once; the comment is applied to all files being checked in. To determine which files have changed, you can compare the "lines added, deleted, unchanged" fields in each file delta table.

Starting a New Release

To create a new release of a program, specify the release number you want to create when you check out the file for editing, using the -rn option to edit; n is the new release number:

$ sccs edit -r 2 program.c 

In this case, when you use delta with the new version, it will be the first level delta in release 2, with SID 2.1. To change the release number for all SCCS files in the directory, use:

$ sccs edit -r 2 SCCS

Temporary Files Used by SCCS

When SCCS modifies an s.file (that is, a history file), it does so by writing to a temporary copy called an x.file. When the update is complete, SCCS uses the x.file to overwrite the old s.file. This ensures that the history file is not damaged when processing terminates abnormally. The x.file is created in the same directory as the history file, is given the same permissions, and is owned by the effective user.

To prevent simultaneous updates to an SCCS file, subcommands that update the history create a lock file, called a z.file, which contains the PID of the process performing the update. Once the update has completed, the z.file is removed. The z file is created with mode 444 (read-only) in the directory containing the SCCS file, and is owned by the effective user.