Glossary

Next: Concept Index, Previous: BSD Code, Up: Top

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.