The checksum is followed by the delta table. Each entry describes one version stored in the history file, and is composed of three lines plus some comment lines. The first line introduces a new delta table entry and has the form
^As 00001/00000/00010
The three numbers represent the numbers of lines inserted, deleted and unchanged in this version (with respect to its predecessor). For the oldest version in the history file, the numbers of lines deleted and unchanged should be zero and the number of lines inserted is the number of lines in the initial version of the working file. These numbers are always five digits long. If the true count of inserted, deleted or unchanged lines is greater than 99999, then the fields will still only contain 99999.
The second line has the form
^AD 1.5 68/12/31 23:59:59 james 5 4
Here, the ‘D’ indicates that this is a normal delta. The only
other type of delta is the removed delta. Removed deltas are created
with the rmdel program and are labelled with an ‘R’ instead
of a ‘D’. This is followed by the sid, which will have either
two or four fields separated by a decimal point (ASCII code 46 decimal).
A sid with only two fields (release and level) is said to be on the
trunk of the revision tree. A sid with the full four fields (the
last two are the branch number and the sequence number) is said to be a
“branch revision”. Each field in the sid, if present, must
contain a positive integer no larger than 9999. This means that
‘1.0’ would not be a valid version number, for example.
The third and fourth fields on this line are the date and time at which this delta was added to the history file (rather than, for example, the modification time of the working file which was checked in). The year is represented with only two digits, and is deemed to be in the range 1969 to 2068 (see Year 2000 Issues). Despite having only two year digits, the date is in ISO order (year/month/day). The time is indicated using 24-hour clock notation. The date in the above example is the latest date it is possible to represent in an sccs file.
The fifth field is the name of the user who checked this version in. For the gratification of pedants, it should be noted that this is the name associated with the actual user-id rather than the effective user-id, or the name appearing in the system log as the user who logged in on the controlling terminal.
The final two fields are called delta sequence numbers, or
seqnos. They are for the internal use of the implementation and
should not be confused with “sequence numbers”, which are the final
fields of four-field (“branch”) sids. The seqno of the delta
added last will be larger than that of any other delta. Each delta has
a unique seqno. The first of these two fields is the seqno of this
delta itself, and the second field is the seqno of its predecessor (that
is, the version which had been checked out with get -e). The
seqno 0 is special and appears only as the (nonexistent) predecessor of
the first delta.
Since the delta table entries appear in reverse order of addition (i.e. new entries are always added at the top), the initial delta appears at the foot of the delta table. Many of the sccs utilities define their cutoffs in such a way that they can stop traversing the delta table when they find a delta which is too old.
After the ‘^Ad’ line there may be several lines which indicate lists of included, excluded or ignored sequence numbers for this delta. I don't understand this area of the functionality of sccs very well, so any description here may be vague or incorrect. The CSSC implementation may also be incomplete in this area.
The list of included seqnos is introduced with ‘^Ai’, the excluded seqnos with ‘^Ax’, and ignored seqnos with ‘^Ag’. These are followed by a space character, and then the list itself, which is a space-separated list of integers.
If the mr-validation flag (see Flags) was turned on at the time of the creation of this delta, one or more lines of the form
^Am mr1
^Am mr2
^Am mr3
^Am mr4
may occur. These lines constitute a list of Modification Request Numbers, one on each line.
The next part of the delta table entry is the delta commentary. This comment is intended to contain a description of the changes made in this delta, and is written and read by humans. This may extend over one or many lines, each introduced with ‘^Ac’, like this:-
^Ac The end of the world
^Ac as we know it
If there is no comment for a particular delta, because it was suppressed
with the -y option to delta or cdc, or because the
user was presented with a prompt for comments but just typed the return
key, an empty ‘^Ac’ control line will appear at this point.
CSSC is currently slightly incorrect in this area. If the comment is
suppressed with the -y option, it emits no ‘^Ac’ lines at
all.
The BitKeeper suite uses comment lines of the form ‘^AcX’ (where ‘X’ is a non-blank character) to store data which is specific to BitKeeper. This data is ignored by cssc, which provides read-only support for BitKeeper files. These special lines are distinguished from normal comment lines by the fact that there is no space after the ‘c’:-
^AcHathlon.transmeta.com
^AcK09043
^AcParch/arm/boot/Makefile
^AcRe1f91d8bfa21c521
^AcV4
^AcX0x821
^AcZ-08:00
Some sccs files contain an MR list which follows rather than precedes the comments for a delta, but this is unusual.
The comment block, and in fact the whole delta table entry, is terminated by a control line of the form
^Ae
To illustrate this further, here are two more delta table entries from an sccs file:-
^As 00001/00000/00007
^Ad D 1.2 99/12/31 23:59:59 mcvoy 2 1
^Ac Added an extra line
^Ae
^As 00007/00000/00000
^Ad D 1.1 69/01/01 00:00:00 dmr 1 0
^Ac created at the dawn of time
^Ae