## Glossary

archive

  In the context of SCCS and CSSC, This means the same as “history file”.

branch

  Notionally, a branch is a parallel or forked stream of changes. See “branching”.

body

  The actual data within the version-controlled file is called the “body”, though this is also sometimes used to refer to that part of the SCCS history file that contains data from the body of the controlled file (that is, information from the file as opposed to information about the file).

branching

  Multiple lines of development are called branches; a branch is created by editing a version of a file which already has a derived version (e.g. editing version 1.2 when version 1.3 already exists).

checkin comment

  The `delta` program asks for a checkin comment; this is a comment which summarised the nature of the change which has just been made to the file.

controlled file

  This is the (working copy of a) file which is version-controlled with an SCCS history file (that is, a file which is managed by SCCS or CSSC).

d-file

  See Filenames.

delta

  Each revision of a controlled file, as recorded in an SCCS file is called a delta. This is also the name of the program used to check in such changes to the file.

delta table

  This is the section of the SCCS file which records information about each change that has been made (other than the actual contents of the file at that version).

excluded delta

  An excluded delta is one which was specified with the `-x` option to `get`. See Options for `get`.

g-file

  See gotten file.

gotten file

  This is the working copy of the file; this is read-only unless the file has been checked out for editing.

history file

  Also known as an SCCS archive or “s-file”. When SCCS or CSSC is used to keep a historical record of previous versions of the contents of a file, the file in which this historical information is recorded is called the “history file”. Sometimes there are known as “s-files” or “archives” (though “archive” is more often used in relation to the `ar` and `tar` utilities).

ignored delta

  An ignored delta is one which was specified with the `-g` option to `delta`. See Options for `delta`.

included delta

  An included delta is one which was specified with the `-i` option to `get`. See Options for `get`.

keyword

  It is sometimes useful to include information in the gotten file about what its version number is and so on. Since this information changes with each revision of the file, it makes sense for SCCS (or CSSC) to keep track of this information and place it in the gotten file accordingly. If a file is checked out for editing, placeholders can be edited into the file which; these are later expanded when the file is checked out read-only. See Keyword Substitution. The same name is also sometimes used for the argument following the `-d` option for `prs`. See Data Keywords for the `-d` option of `prs`.

level

  The second component of the SID.

MR number

  Modification Request numbers; if the ‘`v`’ flag is set in the SCCS file, you will be prompted for “MR numbers” when you check in a new revision. These are not used internally by CSSC but may be used to link changes to external things (for example bug report numbers). See Options for `delta`.

p-file

  See Filenames.

q-file

  See Filenames.

release

  The first component of the SID.

revision

  A revision is a specific version of a file which is controlled with an SCCS history file.

sequence number

  The “sequence number” is a decimal number used within the SCCS history file to identify a particular revision (or delta) of the file. These numbers are normally not user-visible (except in the output of `prt` and `prs`). These are sometimes referred to as a “seqno” in order to distinguish them from the fourth component of a SID.

s-file

  The SCCS history file is sometimes referred to as the s-file. See also Filenames.

SID

  Each revision of a file controlled with an SCCS history file is identified by a “SID”. This is a series of numbers separated by dots. A complete SID always has either two components (for revisions which lie on the trunk) or four components (for revisions that lie on a branch). Examples are 1.1, 1.2 (which both lie on the trunk), 1.3.1.1, 1.3.1.2 (which both lie on a branch) and 1.3.2.1 (which lies on a different branch). The four components of the SID are, left to right, the release, the level, the branch and the sequence number. See also sequence number, above.

trunk

  The trunk consists of those deltas within a history file which do not lie on branches; trunk revisions have only two components in their SID. Normally these are the main sequence of changes to the file.

x-file

  See Filenames.

z-file

  See Filenames.