				SCCS
 
	SCCS, the Source Code Control System, provides a unified
and consistent technique for managing source code (ASCII text) and
the corrections, enhancements, and modifications thereto. The fun-
damental unit upon which SCCS operates is the MODULE which may be
of any size although good coding practice suggests that MODULEs
should be unifunctional and hence, compact. In our development
system, a MODULE is a file and a file resides in a directory, the
User File Directory or UFD. As a MODULE evolves, corrections and/or
additions (changes) to the source code of the original MODULE
accumulate as a function of time. Those changes to a MODULE that
arise at any one point in time (a single editing session) are
collectively referred to as a CORRECTION SET or DELTA. A COR-
RECTION SET is a file of differences. A CORRECTION SET when
applied to the original MODULE(file) takes the original source
code to the current(most recent) version of the source code. A
collection of these CORRECTION SETs therefore represents the
evolutionary history of the MODULE with which they(the CORRECTION
SETs) are associated. It also follows that if one preserves the
original MODULE(file) and all of the CORRECTION SETs(files) that
apply to it, it is possible to regenerate the source code for
a MODULE at any level of correction/modification.

	SCCS in our development system is implemented as an interactive
indirect command file. SCCS may be invoked at a terminal by typing:
 
			@[3,1]SCCS<cr>
 
in response to the MCR prompt. SCCS will then identify its presence
and ask whether the user desires long dialog. If long dialog is sel-
ected the questions asked will be somewhat verbose and where approp-
riate, preceded by explanatory text. SCCS may be executed in any of
four(4) operating modes:
 
	1)EDIT MODE	-generates CORRECTION SETs with initialed and
			 dated audit trails and then applies the COR-
			 RECTION SET to generate the most recent ver-
			 sion of the MODULE.
 
	2)RESTORE MODE	-regenerates the source code for a MODULE at
			 any level of correction/modification using
			 the original MODULE and the appropriate COR-
			 RECTION SETs as input.
 
	3)FREEZE MODE	-enables the user to apply some or all of the
			 CORRECTION SETs for a MODULE in a permanent
			 manner such that a "new" original MODULE is
			 generated by applying one or more of the COR-
			 RECTION SETs. Those CORRECTION SETs which were
			 applied are then deleted and any remaining COR-
			 RECTION SETs are resequenced.
 
	4)DCN MODE	-enables the user to declare that one or more of
			 the CORRECTION SETs for a MODULE are to be col-
			 lectively referred to as a DCN (Design Change
			 Notice) for documentation purposes. Neither the
			 original MODULE nor any of its CORRECTION SETs
			 are disturbed. The DCN file for a MODULE is thus
			 a collection of CORRECTION SETs for a given
			 MODULE. The audit trail for this DCN file incor-
			 porates the DCN document number for identification
			 purposes. DCN files, unlike CORRECTION SETs, cross
			 module boundaries. Thus, in all but the trivial
			 case of a DCN associated with a single MODULE, the
			 DCN file will contain corrections to a series of
			 MODULEs and the DCN file for a single MODULE will
			 be an integral part thereof and have no distinct
			 existence. SCCS produces a document on the line
			 printer which details the module(s) and cor-
			 rection set(s) incorporated in the DCN.

	SCCS has a great deal of built in flexibility. The user may escape
from SCCS EDIT mode by typing CTRL/Z or <ESCAPE> in response to any question.
This stops the SCCS process in its tracks and no modifications will be made.
When SCCS prompts for MODE (above), the user may respond with the single
first letter of the desired MODE, or the three letter mnemonic for the
desired MODE (EDI, RST, FRZ), or the full name of the desired MODE (EDIT,
RESTORE, FREEZE, or DCN). The month of the year may be input either as the
full name of the month or the three letter standard abbreviation. When
SCCS prompts for MODULE name, enter only the filename of the MODULE, not
the device, or UIC string, or the filetype. When responding to the audit
trail question in EDIT mode, keep in mind that the question refers to the
appearance of the audit trail in the updated MODULE. The audit trail is
always present in the CORRECTION SET. The user should never request an
audit trail in FORTRAN source code or any source code which does not identify
a comment as beginning with ";" or in ASCII text whose readability would
be adversely affected by the appearance of the audit trail. SCCS utilizes
either of the two DEC RSX editors, EDI or EDT, at the user option.
CORRECTION SETs as files are identified by the file extension .COR. They
will always be contiguous in version number: 1,2.... They have the pro-
tection code [R,R,R,R]. The original version of a MODULE always has a
version number of 1 and the protection code [R,R,R,R]. The latest version
of a MODULE always has a version number of 2 with standard protection
since it can be regenerated at will. No other version numbers are tolerated.
RESTOREd versions of a module are identified by the extension .RST.
DCN files are identified by the extension .DCN. SCCS uses several file
extensions for its internal manipulations. These extensions are to be con-
sidered reserved. They are:
 
				.COR
				.MOD
				.CHG
				.TMP
				.SAV
				.RST
				.HDR
				.FIX
				.DCN
 
The user should never create or manipulate any files in his directory with
these extensions if SCCS controls any files in that directory. Doing so will
lead to unpredictable results.
 
	RULES AND REGULATIONS (DO'S AND DON'TS)
 
a) The user must create or copy the original version of a module in(to)
   his directory before invoking SCCS. This MODULE (file) must have a
   version number of 1.
b) The user should never edit a MODULE independently of SCCS if that
   MODULE is controlled by SCCS.
c) The user should never edit a CORRECTION SET either independently or
   under the control of SCCS.
 
 
				APG 1/24/79 a.k.a. 79-04-04
