Each section is described in detail below.
This document describes the SCCS v4 history file format that has been introduced in February 1977 as well as the SCCS v6 enhancements that have been introduced in September 2011.
Entries of the form ddddd represent a decimal number. In the statistics line from the delta table, this represents a five digit string (a number between 00000 and 99999). Other numbers are not artificially limited to a specific range. Serial numbers and SID number components may be any non negative number representable by a signed 32 bit integer.
The usable range on a specific machine is however limited by the available virtual memory. This implementation needs virtual memory that is approx. 100 times the highest serial number from the file. If a SCCS history file contains one million deltas, this implementation needs 100 MBytes of virtual memory to process the deltas.
The value of the checksum is the low 16 bits from the signed sum
of all characters, except those contained in the first line. When reading
files, values computed as the unsigned sum of all characters are accepted
too. The ^Ah provides a 16 bit magic number of (octal) 064001
in PDP-byteorder and 000550 in Motorola-byteorder ("\001\150").
The checksum line was changed in order to prevent historic SCCS implementations from accidentally ignoring project-related (project-global) locks. It permits future versions to decide on different checksum algorithms without a need to again introduce a new history file format.
In SCCS v6, the ^Ah magic is not directly followed by the checksum but by the letter V that is followed by the SCCS version number. The version number is followed by a comma and the checksum algorithm name. The string sum is interpreted as the SCCS v4 checksum method. The SCCS v4 checksum entry must directly follow the SCCS version number.
Further checksums may be added in the future, e.g.:
but the sum= entry is mandatory. SCCS v6 currently does not implement checksum algorithms other than sum. Other entries are currently ignored when reading and silently discarded when copying or modifying files.
^As inserted/deleted/unchanged ^Ad type sid yr/mo/da hr:mi:se username serial-number \ predecessor-sn ^Ai include-list ^Ax exclude-list ^Ag ignored-list ^Am mr-number ... ^Ac comments ... ... ^Ae
The lines with the entry type ^As, ^Ad and ^Ae are mandatory.
The first line (^As) contains the number of lines inserted/deleted/unchanged respectively. The actual values for inserted/deleted/unchanged are five digit numbers. If an actual value is greater than 99999, then it is replaced by 99999.
The second line (^Ad) contains the type of the delta:
followed by the SCCS ID (SID) of the delta, the date and time of creation of the delta as local time, the user-name corresponding to the real user ID at the time the delta was created, and the serial numbers of the delta and its predecessor, respectively.
The year is either represented by a two digit year in the range 69..99 for 1969..1999 or 00..68 for 2000..2068 or by a four digit year number. Year numbers before 1969 are currently not supported. Older SCCS versions may not be able to understand four digit year numbers.
The user-name must not contain a space character, as space is the field separator in this file format. Since some non-POSIX platforms permit a space in the username, it is converted into a `_' by the SCCS software before storing it in the history file.
The ^Ai, ^Ax, and ^Ag lines contain the serial numbers of deltas included, excluded, and ignored, respectively. These lines do not always appear.
The ^Am lines (optional) each contain one MR number associated with the delta.
The ^Ac lines contain comments associated with the delta. If there is more than one comment line, each comment line appears after a separate ^Ac lead in.
The ^Ae line ends the current delta table entry.
^As inserted/deleted/unchanged ^Ad type sid yr/mo/da hr:mi:se [.ss]+-hhmm username \ serial-number predecessor-sn ^Ai include-list ^Ax exclude-list ^Ag ignored-list ^Am mr-number ... ^AS sid-specific metadata ... ^Ac comments ... ... ^Ae
The second line (^Ad) must have a four digit year number, may add sub-second time stamp granularity and must have a time zone offset.
Optional sub-second time stamp granularity is introduced by a dot `.' and adds one to nine decimal digits that represent a fraction of a second up to nanosecond granularity. This number must be non-negative.
The time zone offset starts with a `+' or a `-', the
value 0000 starts with a `+', negative values start with a
`-'. Positive values are east to GMT. The first two decimal digits
represent the hour part of the GMT offset, the last two decimal digits
represent the minute part of the GMT offset. A granularity less than a
minute cannot be represented.
The date and time part represents local time as in SCCS v4 entries, but the mandatory timezone offset makes the time unique. The time stamp:
represents 2012, the first of February 12:00 GMT which is 13:00 MET.
The ^AS lines introduce SID specific SCCS v6 extensions. SID specific extension lines are in name/value format and take the form:
The following name parameters are defined:
The project set home is a directory that holds a directory .sccs for project specific SCCS metadata. The location of this directory .sccs is searched for by scanning the filesystem towards the root directory, starting from the current working directory. All files that belong to a project must be below the project's file set home directory.
See also the description for the same keyword in the section for global meta data, where the the initial file name is recorded.
The data format in the extended SCCS delta entry (^Ad) and the SCCS SID specific metadata (^AS) is not accepted by historic SCCS implementations. When converting a SCCS v6 history file back to a SCCS v4 history file, these entries are converted into special comment at the beginning of the comment section. While converting, a copy of the unmodified ^Ad entry is kept as ^Ac_d and ^AS is turned into ^Ac_S.
Flags may be selected from the set of 26 lower case characters in the range `a'..`z'. Historical SCCS implementations will dump core in case a character outside the specified range appears as flag character.
The following flags are defined in order of appearance:
The v flag and the z flag are mutually exclusive.
If the parameter value to the `i' flag is not
empty, then it holds a line fragment with keywords starting with a
`%Z%%M% %I% %E%'
This line fragment needs to exactly match a part of a line in the file and to result in expanded keywords. Otherwise an attempt to check in a new delta will fail. The parameter to the `i' flag is a SUN extension.
The v flag and the z flag are mutually exclusive.
This flag is a SUN extension that does not exist in historic sccs implementations.
This flag is a SCHILY extension that does not exist in historic sccs implementations.
This version of SCCS implements read only compatibility support for a SCO SCCS extension that sets the executable bit in the file permissions of a gotten file if the x-flag was set in the history file with no parameter. This version of SCCS does not allow to set this variant of the x-flag in the history file. If you like to get executable files from SCCS, set the executable bit in the file permissions of the history file.
If this version of SCCS is used to create the history file and the executable bit was set in the original file, SCCS automatically sets the executable bit in the history file and thus retains the executable bit in the gotten file.
This flag is a SUN/SCHILY extension that does not exist in historic sccs implementations.
No SCCS v6 flags are currently defined.
Historical SCCS implementations do not complain about SCCS v6 flags when reading SCCS history files and retain SCCS v6 flags when modifying history files. This is why SCCS v6 flags may be kept unmodified when converting a SCCS v6 history file back to a SCCS v4 history file.
The following keywords are defined:
See also the description for the project set home in the
documentation for the same keyword in the section for SID specific meta
data of the delta table. In case of a rename, the new file name is
recorded in in the SID specific meta data of the delta table.
The pseudo random number is a hexadecimal string that represents the microseconds since Jul 13 11:01:20 2012 GMT when initially creating the sccs history for a specific file. Including microseconds gives sufficient randomness to make clashes rare.
With a 32 bit signed time_t, 52 bits in the pseudo random number are sufficient. With a 64 bit pseudo random number, more than 500000 years are covered.
The minimal length for the pseudo random number is thirteen hexadecimal characters. If the number could be represented with less digits, it is left filled with zeroes. This allows to have a unique length for this number until Mar 31 10:55:07 2155 GMT.
The random metadata is mandatory for SCCS v6 history files. The initial path tag may be recorded later but before the changeset file is created. The value for this metadata tags must not change.
Historical SCCS implementations do not complain about SCCS v6 metadata when reading SCCS history files and retain SCCS v6 metadata when modifying history files. This is why SCCS v6 metadata may be kept unmodified when converting a SCCS v6 history file back to a SCCS v4 history file.
SCCS reserves the area just before the comments section for extensions by only checking the content at this location for syntactic correctness. Unknown elements at this location are still copied and kept intact when the historyfile is modified. SCCS v6 already introduced SCCS v6 flags and global SCCS v6 metadata as extensions, so future extensions must appear past the SCCS v6 metadata.
There are three kinds of control lines: insert, delete, and end, represented by:
^AI ddddd ^AD ddddd ^AE ddddd
respectively. The digit string is the serial number corresponding to the delta for the control line.
An inserted block of lines looks this way:
^AI ddddd block of data ^AE ddddd
A deleted block of lines looks this way:
^AD ddddd block of data ^AE ddddd
The block of data may contain control lines with other serial numbers.
The old-sid is the SID that was checked out with get -e, the new-sid is the SID that will be used for the new version when delta is called. The username is the user-name corresponding to the real user ID at the time get -e was called. The date and time fields are in the same format as used in the delta table of the s.file as described in sccsfile(5) for SCCS v4. In order to grant POSIX compatibility, a two digit year is used between 1969 and 2068. For years outside that range, a four digit year is used. The following fields are only present when one or more of the -i -x or -z options have been specified on the command line, they refer to the list of included and excluded deltas or to the CMR list from the NSE enhancements.