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.