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 in response to the MCR prompt. SCCS will then identify its presence. If a file of PRESTORED REPLIES exists in the user's directory then SCCS will simply prompt for the MODULE name (FILENAME and EXTENSION). If a file of PRESTORED REPLIES does not exist then SCCS will pose a question concerning the operating mode of SCCS. The options are: EDIT, RESTORE, FREEZE, or SCO. If the user selects EDIT mode, SCCS will ask the user if he/she wishes to create a file of PRESTORED REPLIES. If the answer is yes, then SCCS will pose the questions and create the file. Otherwise, SCCS will operate in normal dialog mode. If a file of PRESTORED REPLIES exists and the user does not desire to use them or if the user desires RESTORE, FREEZE, or SCO mode, then replying to the MODULE question with causes the mode question to be posed. One question which is posed in each operating mode con- cerns long dialog. Long dialog is available for the inexperienced user who wishes to be guided through the SCCS process with maximum information concerning the internal workings of SCCS being presented along the way. 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. EDIT mode is the only mode for which PRESTORED REPLIES are available. 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)SCO 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 SCO (Software Change Order) for documentation purposes. Neither the original MODULE nor any of its CORRECTION SETs are disturbed. The SCO file for a MODULE is thus a collection of CORRECTION SETs for a given MODULE. The audit trail for this SCO file incor- porates the SCO document number for identification purposes. SCO files, unlike CORRECTION SETs, cross module boundaries. Thus, in all but the trivial case of a SCO associated with a single MODULE, the SCO file will contain corrections to a series of MODULEs and the SCO 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 SCO. SCCS has a great deal of built in flexibility. The user may escape from SCCS EDIT mode by typing CTRL/Z or 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 SCO). When SCCS prompts for the MODULE name, enter the FILENAME and its EXTENSION, not the DEVICE or UIC string. When re- sponding 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 any one of the four DEC RSX editors: EDI, EDT, TECO, or KED 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. SCO files are identified by the extension .SCO. 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 .SCO 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) If the user attempts to bring a pre-existing module under SCCS control, the module must have a version # of 1 and be the only version of that module in the directory. 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. THIS TEXT DOCUMENTS SCCS VERSION 2.03 APG 3/20/80