Applying RCS and SCCS From Source Control to Project Control By Don Bolinger & Tan Bronson 1st Edition September 1995 1-56592-117-8, Order Number: 1178 528 pages, $34.95

Chapter 4
Basic Source Control Using SCCS

Contents:
Background
Conventions
Basic SCCS Commands
Summary

The Source Code Control System, or SCCS, was initially developed in 1972 by Marc Rochkind at Bell Telephone Laboratories. Though SCCS lacks some of the amenities of RCS (a natural result of its early date of development), it is a generally equivalent system and has a few capabilities that RCS does not. As we just did for RCS, here we describe the most basic abilities of SCCS through a look at the source file modification cycle.

Background

As you might guess from the company where it originated, SCCS traditionally has been part of AT&T-derived UNIX distributions. Though its initial implementation was not done in a UNIX environment, SCCS was quickly reimplemented under UNIX V6 and was distributed as part of the Programmer's Workbench (PWB) from AT&T until the advent of System III and System V.[1] Nowadays, SCCS is a standard part of System V.

[1] A different version of SCCS, also descended from the PWB release, does exist in Berkeley UNIX distributions; but the BSD version has not evolved in step with the AT&T version, and our description applies to the BSD version only in general terms.

In this book we present the SCCS implementation that is currently available in System V.4, which is a superset of the one described in Issue 3 of the System V Interface Definition [USL92]. This version of SCCS contains the commands listed in Table 4.1.[2]

[2] Strictly speaking, the vc(1) command is not part of SCCS but is currently packaged with the system. The command provides the ability to conditionally filter lines of text out of or into a source file according to the value of user-specified keywords in a way very similar to the C-language preprocessor. We do not describe it in this book.

Table 4.1: The SCCS Command Set

Command	Description
admin	Create and administer SCCS files
cdc	Change the delta commentary of an SCCS delta
comb	Combine SCCS deltas
delta	Make a delta (change) to an SCCS file
get	Get a version of an SCCS file
help	Obtain explanations of error messages
prs	Print an SCCS file
rmdel	Remove a delta from an SCCS file
sact	Print current SCCS file-editing activity
sccsdiff	Compare two versions of an SCCS file
unget	Undo a previous get of an SCCS file
val	Validate SCCS file
vc	Version control
what	Identify SCCS files

The only way in which System V.4 SCCS differs from the SCCS described in the SVID is that it includes the cdc(1) and comb(1) commands, which do not appear in the SVID. Since the SVID is the authoritative presentation of System V command interfaces, you could view these two commands as "deprecated" by their omission. Certainly, their usefulness is limited, as we'll see later.

Conventions

Before we present the basic SCCS commands, we define some terms that are useful in talking about SCCS. Then we touch on command-line conventions, particularly on how you specify files, which is quite different in SCCS than in RCS.

Nomenclature

When SCCS creates an archive file for a given source file, the archive file name is the source file name with s. prefixed to it. So if you had a file xform.c for which you'd created an archive file, s.xform.c would become the name of the archive file. The s. refers to "SCCS," and SCCS documentation calls these archive files "SCCS files."

In traditional documentation on SCCS, especially manual pages, a number of other terms are fairly regularly used, as well. Each revision of a source file recorded in an SCCS file is called a delta, and the revision number of each revision is referred to as an SID (for SCCS ID). The SCCS manual pages call a source file revision retrieved from an archive file a g-file (for "get-file" or "gotten-file"). This is part of a naming scheme that includes various other internal and temporary files that SCCS creates in the course of doing business. There are no regularly used terms for the operations of adding a new delta to an SCCS file or of retrieving an existing delta.

As we've already mentioned, in this book we always use the equivalent terms from RCS, rather than trying to use both SCCS and RCS terminology. We think that using only one set of terms makes the book easier to read. And we think that the RCS terms are, simply, better (more descriptive and evocative) than their SCCS counterparts. So bid adieu to "g-file"--you won't see it again. Table 4.2 lists the various SCCS terms that are used in traditional documentation and the terms that we use instead (all of which come from RCS).

Table 4.2: SCCS Terms and Equivalents

SCCS Term	Term Used in Book
delta	Revision
g-file	Working file
SID	Revision number
add a delta	Check in a revision
retrieve a delta	Check out a revision

Command Lines

SCCS accepts command lines in the same classic UNIX format as RCS. That is, SCCS commands expect a command line that consists of a command name followed by one or more file names. The file names may be (but don't have to be) preceded by one or more options. If given, options change how the command works. So to summarize, a command line looks like this:

command-name [options] files

Each option begins with a hyphen, which is what distinguishes it from a filename. After the hyphen comes a single letter that identifies the option; then (for some options) comes a string that serves as a value for the option. Never insert whitespace between an option letter and its value--let them appear as one argument on the command line. (The first argument that doesn't start with a hyphen is assumed to begin the filename arguments for the command.) Each file named on a command line can be either an SCCS file or a directory containing SCCS files, as we describe below.

Thus a typical command might be

$ get -r1.1 s.xform.c

This invocation of the get(1) command specifies one option (-r, which has the value 1.1), and specifies one file, s.xform.c.

One final note is really unrelated to SCCS but rather relates to entering quoted strings on a shell command line. As we'll see, you sometimes have the option of entering a description either at a prompt from the program you're running or directly on the program's command line. If you want to give the description on the command line, you'll need to enter it as a quoted string (because it will contain whitespace). And if you want to continue the description over more than one line, you'll have to use whatever convention your shell supports for continuing a command line.

For instance, the -y option to the delta(1) program specifies comments for a check-in operation. If you want to give a multiline comment and you're using csh(1) (or derivatives) as your shell, you need to precede each carriage return in the commentary with a backslash:

% delta -y"Fix CR 604: vary conditioning algorithm according to\ 
? range data supplied by caller." s.filter.sh

However, under the Bourne shell (or ksh(1) or bash(1)), as long as the value for -y is quoted, you don't need to do anything special to continue the comments onto a second line:

$ delta -y"Fix CR 604: vary conditioning algorithm according to
> range data supplied by caller." s.filter.sh

Naming Files

File naming on SCCS command lines is mostly more primitive than for RCS. If you want to refer to an individual file, you must give an SCCS filename; a source filename will not work. An SCCS command tries to use an SCCS file with exactly the name you specify--the command makes no changes of any kind to the name in looking it up. The only extension SCCS allows to this lookup procedure is that you may specify directory names instead of the names of individual files. The command will then try to process all SCCS files (that is, all files whose names start with s.) in each directory named. Using a directory name, rather than wildcards, to name all of the SCCS files in the directory helps you to avoid including non-SCCS files by accident when you run an SCCS command.

One additional bit of flexibility is that SCCS commands can read their set of filenames from their standard input. To get this behavior, you specify - (a hyphen) on the command line as a filename.[3] So another way to specify the command line that we just saw would be

[3] The hyphen can appear in addition to other filenames as well and will cause standard input to be read at that point in the list of files.

$ echo s.xform.c | get -r1.1 -

Naturally, in realistic cases the set of input files to get would not be so easy to come up with. This convention is really meant for use within command scripts; it's especially useful when you operate on very many filenames at once, since it avoids potential restrictions on command-line length.

Getting Error Information

As we will see in presenting the basic SCCS commands, error messages that are output by the system include a short identifier that you can use to obtain more information about the error that just occurred. You do that by supplying the identifier to a separate program called (rather unhelpfully) help(1). Say, for instance, that you supply a file name to an SCCS command that is not a legal SCCS filename. The resulting exchange might look like this:

$ admin xform.c
ERROR [xform.c]: not an SCCS file (co1)
$ help co1
co1:
"not an SCCS file"
A file that you think is an SCCS file
does not begin with the characters "s.".

So in other words you run the admin(1) command, which informs you of an error, and you then run the help command to find out more about what went wrong.

Basic SCCS Commands

Here we describe one iteration of the source file modification cycle, using SCCS commands to implement each operation in the cycle. We also present a few other basic commands that aren't strictly part of the cycle. As for RCS, the cycle uses only some of the SCCS commands and exercises them only in the simplest way. Later chapters will present more of the capabilities of the full SCCS command set.

Figure 4.1 depicts the basic source control operations. This is the same picture we presented as Figure 2-1, but annotated to show which SCCS command actually implements each operation. Once again, the central part of the figure shows the modification cycle.

Figure 4.1: Basic source control operations in SCCS

Let's cover each of the operations in more depth. Roughly speaking, we'll describe them in the order in which they appear in the figure, working from top to bottom.

Creating an SCCS File

You create an SCCS file with the command admin. Normally, the command line names both the source file that you want to check in to the new archive file and the archive file itself. You name the source file with the -i option. A typical exchange looks like this:

$ admin -ixform.c s.xform.c
No id keywords (cm7)

This command creates the archive file s.xform.c and checks in the source file xform.c as its initial revision.

The output from admin indicates that xform.c did not contain any "identification keywords." As we mentioned in Chapter 2, The Basics of Source Control, SCCS (or RCS) allows you to add special strings to your source files that the system can update automatically to reflect information about a particular working file. For instance, the most commonly used keywords expand to the name of the file and its SCCS revision number. If properly used, these keywords ensure that you always can tell what revision of a source file you're working with. We will discuss them further in Chapter 8, Managing the Mechanics of Releases.[4]

[4] We strongly recommend that you use keywords; although we won't use them in the rest of this chapter, we will be introducing them shortly. By default, SCCS does not oblige you to do so. That is, commands will work on source files that don't contain keywords. However, you should always use keywords, since they can unambiguously indicate what revision of an archive file your working file came from.

In contrast to ci(1), admin does not prompt you for a description of the archive file you're creating, although you can provide a description via a command-line option (see below). Also unlike ci, admin does not delete the original copy of your source file once it has created a new archive file. To ensure that your source file obeys SCCS conventions for file permissions (and keyword expansion, once you're using keywords), we suggest that you delete your source file manually once admin -i has been run successfully and that you then run get to extract your source file from its new archive file. The sequence of commands might look like this:

$ admin -ixform.c s.xform.c
No id keywords (cm7)
$ rm xform.c
$ get s.xform.c
1.1
127 lines
No id keywords (cm7)

Now you can be sure that your source file "looks like" a working file--that it's read-only and that any identification keywords you inserted are expanded within the file (though that's not relevant here).

When you check in the initial revision of an archive file, admin really creates two descriptions. The first description is for the file itself. The second description is a "log message" for the initial revision. By default, admin assigns a log message of this form to the first revision: date and time created 95/04/23 14:32:31 by rully This default message merely repeats parameters that are stored elsewhere in the archive file: when and by whom the revision was created. If you prefer something more informative, you can include a log message on the admin command line using the -y flag, like this: $ admin -y"As ported from 9000 engineering group sources, > version 4.13." -ixform.c s.xform.c Of course, the message needs to be quoted, and the usual rules apply if you extend it across multiple lines. Completely apart from the log message, you can also specify a description of the archive file itself when you first create it, or later on, by using the -t option to admin. This option takes as its value the name of a file where you've stored the description. So the following sequence would assign a description to s.trig.c: $ cat > xform.desc Matrix transform routines, for single-precision data. ^D $ admin -txform.desc s.xform.c Why have descriptions both of the archive file and of its initial revision? One useful distinction the two can capture is between the role of the file in your project (the archive file description) and the origins of the source file going into the first revision (the revision log message).

A second way of creating an SCCS file is to create an empty file, then to use the get and delta commands (described in the next sections) to check in a source file to it, via an ordinary iteration of the source file modification cycle. To create an empty SCCS file, you use the -n flag to admin and name only the SCCS file on the command line:

$ admin -n s.xform.c

This command line creates an empty SCCS file named s.xform.c. If you have preexistent files to put under source control, using -i to do so will normally be easier than using -n, since with -n you have to be sure not to overwrite your source files when you do the subsequent get (check-out) commands from the archive files. However, you should note that, although admin -n lets you specify SCCS filenames like any other command, admin -i permits you to name only one SCCS/source file pair on its command line and does not accept directory names. So this command line, which tries to create two SCCS files, is illegal:

$ admin -ixform.c s.xform.c -ibessel.c s.bessel.c
ERROR: key letter twice (cm2)

You can give -i only once, just as the error message implies.

As its name indicates, admin performs a variety of administrative tasks on SCCS files. One very visible way in which SCCS differs from RCS is that it views the creation of a new SCCS file as a special, administrative operation. As we've seen, with RCS you use the ci command both to create an RCS file and to check in a new revision to an existing RCS file. In SCCS you use admin to create a new SCCS file, then use delta to check in new source file revisions to it, once it exists. The RCS approach, of course, is simpler, if less administratively sound.[5]

[5] In philosophical terms, the SCCS approach to archive file creation may be more "correct," since creating an archive file is indeed a more privileged operation distinct from adding a revision to an existing archive file (and so should be administered separately). In day-to-day use, however, the need to use a separate command to create an SCCS file is something of an annoyance.

Getting a Working File for Reading

You check out a source file from an existing SCCS file with the command get. In the simplest case you just name the SCCS file from which you want to get the source file:

$ get s.xform.c
1.1
127 lines
No id keywords (cm7)

This command will get the latest revision of the source file stored in s.xform.c and put it into a working file called xform.c. In this case the output notes that revision 1.1 was gotten and that this revision of xform.c contains no SCCS identification keywords. As we've noted, though this is inadvisable, by default it's not illegal; get obtains the file anyway.

Since the command line doesn't indicate that you want to modify xform.c, the file is created read-only. This is a reminder that you shouldn't change it unless you coordinate your change with the SCCS file (by locking the revision of s.xform.c that you want to modify).

If a writable file already exists with the same name as the working file that get is trying to create, the command will terminate without creating a new file and will inform you of the error:

$ get s.xform.c
ERROR [s.xform.c]: writable `xform.c' exists (ge4)

Unlike with RCS, here you don't have the option of continuing the get operation. If you don't want the existing file, you have to delete or rename it manually.

CAUTION: As we said in Chapter 2, The Basics of Source Control, get will silently overwrite any read-only copy of a file that already exists with the same name as the working file it's trying to create, on the assumption that the existing file is the result of a previous get for reading. So if a file is under source control, do not try to maintain changed copies of it manually (i.e., outside source control).

Getting a Working File for Modification

Just like in RCS, in SCCS if you want to change a source file that you've put under source control, you need to check out a writable copy of it. Here, you do that by adding the flag -e to the get command line. So to get xform.c for modification, you could use the command

$ get -e s.xform.c
1.1
new delta 1.2
127 lines

If you compare the output from this command to the output from the last get we looked at, you'll notice two differences. First, the current output confirms that a new revision will be created from your working file. The number given here is the revision number that will be assigned to your changed working file when (and if) you put it back into the archive file. Second, get does not complain in this case about missing identification keywords. This is because get does not expand keywords when a working file is created for modification, even if there are some present--so it doesn't complain when it finds nothing to expand.[6]

[6] We'll discuss keyword states further in Chapter 10, Release Mechanics in SCCS. SCCS "expands" keywords that it finds in working files gotten for reading only but does not expand keywords in working files gotten for modification. RCS has no distinction between expanded and unexpanded keywords.

Though the output from get doesn't say so, the success of the command means that you've locked the revision of s.xform.c that you're modifying (revision 1.1 in this case). Since you have the lock, you have the exclusive right to change this revision of the file and eventually to submit your working file as the next revision in the archive file.

If someone else already had locked the revision you requested, you would not be able to lock it yourself. You could still obtain the revision for reading only, however, even if it were locked, because SCCS assumes that you won't modify the file when you get it for reading only. So for example, if you asked to modify the latest revision of s.xform.c but someone else was already changing it, you would see a message like this one:

$ get -e s.xform.c
1.1
ERROR [s.xform.c]: being edited: `1.1 1.2 cullen 95/05/08 13:08:49' (ge17)

The message tells you what revision is being changed (and what new revision is being created). It also points out who is making the changes, as well as when she started making them. This information lets you contact the person who owns the lock if you absolutely need to modify the file now. Perhaps she can check it back in. Even if she can't, waiting is better than circumventing SCCS.

Occasionally, you may need to set a lock in an archive file without checking out a working file. Say, for instance, you're archiving sources distributed from outside your group, you've moved a new distribution into place, and now you want to check in the new version of each file. Checking out working files would overwrite the new sources with the older ones. To prevent the creation of a working file, add -g to the get command line. The command get -e -g simply locks the revision you specify and chooses the number that will be given to any new revision you create. The command get -g (without -e) can be used to verify that a given revision exists in an archive file.

Comparing a Working File to Its SCCS File

SCCS does not provide a command to let you directly compare the current contents of a working file with the SCCS file revision it came from. The closest equivalent to rcsdiff(1)--the command sccsdiff(1)--only compares two revisions already checked in to the SCCS file.

To compare your working file to an SCCS file revision, you have to use a subterfuge. The get command accepts an option, -p, that causes the working file contents obtained to be written to its standard output, rather than put into a file. You can use this option, together with diff(1), to do what you want. For instance, to compare your current copy of xform.c with the most recent revision in s.xform.c, you could use the command

$ get -p s.xform.c | diff - xform.c

(The hyphen given to diff causes it to read one of its input files from its standard input.) This command line would generate output like the following:

$ get -p s.xform.c | diff - xform.c
1.1
127 lines
No id keywords (cm7)
4a5
> j_coord = i_coord - x;
11,12c12,13
<       for (j = j_coord; j < j_max; ++j)
<               if (a[j] < b[j]) {
---
>       for (j = j_coord + 1; j <= j_max; ++j)
>               if (a[j - 1] < b[j]) {
20d20
< j_coord = i_coord - x;

First, you see the status output from the get command, which shows you the number of the revision it got and the number of lines in that revision. Then you see the normal output from diff, with revision 1.1 of the SCCS file shown as the "old" file being compared and your working file shown as the "new" file being compared.

If you want to compare your working file to some other revision of its SCCS file, simply add a -r flag to the get command line to name the revision you want, like this:

$ get -p -r1.1 s.xform.c | diff - xform.c

This command line would use revision 1.1 of the SCCS file as the "old" file to compare.

Finally, if you want to compare two revisions that are already in the archive file, you can (at last!) use the sccsdiff command. Just specify the two revisions you want to compare, using -r flags:

$ sccsdiff -r1.1 -r1.2 s.xform.c 

The sccsdiff command just gets the two revisions you name on the command line, then runs a diff variant called bdiff(1) to compare them. Its output consists solely of the output from bdiff.

The sccsdiff command is implemented as a shell script. Since that made adding frills easy, folks apparently decided to do so. Hence the -p option will cause sccsdiff to pipe its output through the pr(1) utility. The output will be paginated, and a header will be added to each page identifying the file and the two revision numbers being compared. On the other hand, the -s option to sccsdiff changes its internal operation. When bdiff is run to compare the named revisions, it breaks its input files into "segments" of a fixed number of lines and runs diff on each pair of segments. Sometimes, the default segment length is too big for diff to handle. With the -s option to sccsdiff, you can specify a new segment size for bdiff. See your system's documentation for bdiff to find out its default.

Adding a Working File to Its SCCS File

When you want to save the current state of your working file for future reference, you use the delta command to check in the working file to the archive file. Note that delta works only with an existing archive file; to create an archive for the first time, you use the admin command, as we explained earlier. Also, for delta to succeed when you run it, you must have a revision locked (via get -e) in the archive file you want to update.

As usual, you run delta by naming the SCCS file to which you want to add your working file. SCCS then looks for a working file with the same name, minus the s. prefix. So this command would check in xform.c to the SCCS file s.xform.c as a new revision:

$ delta s.xform.c

Like ci, delta prompts you for a description of the changes in your working file. However, the interface is more primitive; you're restricted to 512 characters of commentary, and the first "unescaped" newline[7] in your comments will terminate them. If you want to include a newline in your comments--that is, if you want the comments to appear on more than one line--you have to "escape" the newline by preceding it with a backslash. The whole interaction with delta might look something like this:

[7] "Newline" is UNIX parlance for an end-of-line character (normally a line feed, ASCII LF). Conceptually, it's the character generated when you type Enter or Return at your keyboard.

$ delta s.xform.c
comments?  In function ff1():  move declaration of j_coord; fix\ 
off-by-one error in traversal loop.
1.2
3 inserted
3 deleted
124 unchanged

Notice that, since we wanted our comments to appear on two lines, we had to end the first line of commentary with a backslash so that delta would accept the second line.

Sometimes, you may prefer to give revision commentary directly on the delta command line--this can be handy when you're checking in more than one file and want all of the files to have the same commentary. You do this using the -y option to delta. For instance, the last check-in we showed could be phrased as

$ delta -y"In function ff1():  move declaration of j_coord; fix
> off-by-one error in traversal loop." s.xform.c

Notice that we gave the comments as a quoted string, as they contain whitespace. Since in this example we're using a Bourne-style shell, we extended the comments onto a second line just by typing a carriage return where we wanted it.

Once you terminate your comments, delta outputs the number of the revision it just created in the SCCS file, together with a count of lines inserted, deleted, or unchanged between that revision and the revision you originally extracted with get. By default, delta then deletes your working file so as to encourage you to check out a new working file, with freshly expanded keywords, if you still need the file around.

Two other options change what delta does at check-in time. The -p option makes delta write to its standard output the differences between the checked-in revision and its predecessor. The differences are shown exactly as diff (or sccsdiff) would display them.

The -n option causes the command not to delete your working file after check-in. We don't know of any particular reason to use -n, and we recommend against it, since it encourages sloppiness with keywords. If you decide you do need -n, remember that any subsequent get of the working file will either overwrite the file you kept (if it's read-only) or fail (if the file is writable). To run get successfully in this case, you have to use -g to suppress the generation of a working file.

Discarding a Working File

If, despite your best efforts, you find that your changes to a working file just aren't working out, you can use the unget(1) command to discard them. This command unlocks any revision you currently have locked in the SCCS file and deletes your working file if one exists. (The command doesn't complain if no working file is present.)

To use unget, you simply name the SCCS file for which you want to undo a get:

$ unget s.xform.c

The command above would undo a pending modification to s.xform.c.

If you need to remove a lock you've set in an archive file but want to keep your working file, add the -n option to the unget command line. Then the command won't touch your working file.

Another option you may need is -r, which is required when you've set more than one lock in a file under the same username. Without it, unget can't tell which pending update to the archive file you want to cancel. You use -r to name the new revision you no longer want to create.

Viewing the History of an SCCS File

As we've seen, the delta command asks you for a description of your changes whenever you check in a new revision to an SCCS file. As in an RCS file, in an SCCS file the set of these descriptions forms a history, or log, of all the changes made to the SCCS file since it was created. To display this history, you use the prs(1) command.

You simply give on the command line the name of the SCCS file you want to look at. This command, for instance, would display the log of s.xform.c:

$ prs s.xform.c
s.xform.c:

D 1.2 95/05/10 14:34:02 rully 2 1 00003/00003/00124
MRs:
COMMENTS:
In function ff1():  move declaration of j_coord; fix
off-by-one error in traversal loop.

D 1.1 95/04/23 14:32:31 rully 1 0 00127/00000/00000
MRs:
COMMENTS:
date and time created 95/04/23 14:32:31 by rully

Compared to the default output from the rlog(1) command of RCS, the output of prs is trivial. Following a line naming the SCCS file, a set of lines (or "paragraph") is output describing each revision in the file. Revisions are listed most recent first. The first line in a paragraph specifies the revision number, when and by whom it was created, and the number of lines inserted, deleted, and unchanged between it and its predecessor. Later lines list the modification request numbers associated with the revision and show the commentary entered by the user when the revision was made. (Modification request numbers provide a way of associating a revision with an identifier external to SCCS. We will come back to them in Chapter 10, Release Mechanics in SCCS.)

Cleaning Up an SCCS Source Directory

Unlike RCS, SCCS does not give you the option of automatically using a local subdirectory to store your archive files. SCCS also does not provide an equivalent to rcsclean(1). The lack of automated cleanup means that you're on your own in removing working files you don't need (that is, ones that haven't been changed since they were created). The absence of an "SCCS" subdirectory means that you need to be careful in doing so.

However, SCCS does provide a command to let you see what archive files currently contain a revision locked for editing. The sact(1) utility will examine each archive file you name on its command line, producing a one-line description of each locked revision in the file. If no revisions in a given file are locked, the command says so. For example, if trig.c doesn't currently contain a locked revision but xform.c does, sact output for the two might look like this:

$ sact s.trig.c s.xform.c
s.trig.c:
No outstanding deltas for: s.trig.c
s.xform.c:
1.1 1.2 cullen 95/05/08 13:08:49

As you can see, the output for each locked revision consists of its number and the number of the new revision to be created, as well as who locked the revision and when.

Summary

You need three commands to put and keep files under source control using SCCS: admin, get, and delta. In this chapter we've also introduced the unget command to abort a pending modification to an SCCS file, as well as informational commands sccsdiff and prs, which give you information about the contents of an SCCS file. Finally, we mentioned sact, which can be used to find out which archive files in a set contain locked revisions.

Table 4.3 summarizes the presentation so far, by relating each operation in the source file modification cycle (plus a few others) to the SCCS command that implements it.

Table 4.3: Basic SCCS Commands

Command	Basic Operation
admin -i or -n	Creating an SCCS file
get	Getting a working file for reading
get -e	Getting a working file for modification
get -p plus diff	Comparing a working file against its SCCS file
delta	Adding a working file to an SCCS file
unget	Discarding a working file
prs	Viewing the history of an SCCS file
sact	Seeing which archive files have locked revisions

We'll defer a detailed comparison of RCS and SCCS to Appendix C, RCS and SCCS Compared. For now, we simply repeat that by and large, SCCS has a more primitive user interface than RCS, despite some localized advantages (such as the automated handling of directories containing SCCS files or the mnemonically named unget command). Now that we have introduced both source code control systems, we move on to consider their use in realistic development.

Back to: Sample Chapter Index

Back to: Applying RCS and SCCS: From Source Control to Project Control