Source Code Revision Control Systems and Auto-Documenting
Total Page:16
File Type:pdf, Size:1020Kb
Source Code Revision Control Systems and Auto-Documenting Headers for SAS® Programs on a UNIX or PC Multiuser Environment Terek Peterson, Alliance Consulting Group, Philadelphia, PA Max Cherny, Alliance Consulting Group, Philadelphia, PA ABSTRACT This paper discusses two free products available on UNIX and PC RCS, which is a more powerful utility than SCCS, was written in environments called SCCS (Source Code Control System) and early 1980s by Walter F. Tichy at Purdue University in Indiana. It RCS (Revision Control System). When used in a multi-user used many programs developed in the 1970s, learning from environment, these systems give programmers a tool to enforce mistakes of SCCS and can be seen as a logical improvement of change control, create versions of programs, document changes SCCS. Since RCS stores the latest version in full, it is much to programs, create backups during reporting efforts, and faster in retrieving the latest version. RCS is also faster than automatically update vital information directly within a SASâ SCCS in retrieving older versions and RCS has an easier program. These systems help to create an audit trail for interface for first time users. RCS commands are more intuitive programs as required by the FDA for a drug trial. than SCCS commands. In addition, there are less commands, the system is more consistent and it has a greater variety of options. Since RCS is a newer, more powerful source code INTRODUCTION control system, this paper will primarily focus on that system. The pharmaceutical industry is one of the most regulated industries in this country. Almost every step of a clinical trial is subject to very strict FDA regulations. SASâ programs used to KEY FEATURES OF SOURCE CONTROL UTILITIES summarize and analyze the results of a clinical trial are no RCS does not store the entire version of each file but only the differences between files. Therefore, all versions of a program exception. SASâ programs are considered by the FDA to be an important element of the reliability and accuracy of the information are being saved in a space efficient way. This can significantly reduce the amount of space required to keep all source files. used to approve and manufacture drugs. These programs must Since previous revisions remain easily accessible, all subsequent adhere to FDA regulations, which require extensive design and changes do not overwrite the original. Users are always able to documentation controls. The FDA requires SASâcode to be retrieve any given revision using version numbers, symbolic compliant with a System Development Life Cycle (SDLC). This names, dates, authors and states. Users can retreat to an older includes, but is not limited to, change control, backup/recovery version if they decide that the current version is incorrect, or if and installation procedures. Drug companies must be able to they want to see some text that has since been changed or provide documentation of their software processes and deleted. The only way to permanently delete or corrupt a procedures on demand in order to show their software has been program is to modify a file located in the RCS directory. The safely created and that any changes can be properly managed. ability to recreate old versions of a single file or a group of files allows users to use source code control as a simple backup Regardless of doing a clinical trial, adherence to a SDLC is a system and to recover and modify earlier releases of a product or good systems development practice. Besides helping drug document. By keeping all file revisions in a separate location, companies to meet the FDA regulations, the proper source code control utilities protect these programs from many implementation of a SDLC can reduce development costs and cases of accidental file deletion or corruption. If a user checks out decrease the amount of time it takes to report and analyze a a program and then accidentally removes it they can easily clinical trial. restore the original version of a program since a copy is kept in another location. Source code control refers to controlling the process of modifying software by managing changes. It lets developers control who RCS allows users to perform a limited, personalized backup of can make changes and when these changes are made. It helps to files. If files are being backed up once a week, programmers can prevent conflicts that could arise when many people edit the same check their daily progress notes into a source code control system file. It lets programmers save multiple versions of a file and and have a safe copy in case any of these files are accidentally choose the one they would like to use. It also lets them review damaged or deleted. This should not be viewed as a replacement the history of changes made to a file. for doing system backups because users will still be vulnerable to system or disk problems, but it may provide for a better control There are many different utilities and applications on the market over recovering from a disaster designed to help developers implement a source code control process. This paper discusses two of them, Revision Control RCS may be used to formalize the process of installing the final System (RCS) and Source Code Control System (SCCS). These version of a program from a user's environment to a production are free utilities which are readily available on most UNIX systems environment. A programmer may check in a final version of a and can be also installed on Windows 9x/NT. These systems program from their user area and then send a request to a have been used for many years and there is a lot of free dedicated person to install that version into a production area. documentation regarding their usage. The installation of a program into a production area will be done simply by checking out files from the RCS library. RSC VS. SCCS All changes to a file are automatically stored in a log file within the The SCCS system was developed by AT&T in the 1970s as a RCS subdirectory. Text of each revision, author identification, simple system to control source code development. It includes date and time of check-in and log message summarizing the various features that help support a production development change is kept by RCS. This allows someone the ability to review environment the entire history of a program without having to track down colleagues or look for old notes and comments. In another words, it creates an audit trail. RCS provides a version numbering scheme so users can tell which versions of a file are more recent. back into the RCS library after all necessary changes are made. By saving the history of revisions to a file, users are able to Therefore the RCS library functions as an extra protection layer analyze that history later. This can be invaluable because it gives between production and user areas. them the ability to see the logic of each incremental change that led from the original source to the current source. If several USING RCS people are working with the same version, a source code control One of the reasons why these utilities are so useful is their system can help them coordinate their work by alerting the simplicity. Most of the work is done through few easy-to- programmers, preventing one modification from corrupting the remember commands. Please look through the following other and keeping track of who did what and when. example to see how to use RCS. RCS allows branching of versions. This gives users the capability First, in order for RCS to work there must exist a RCS directory. to perform parallel development of several different variants of the It can be created in the same directory with program files or it may same file. For example, while working on the version 2.0 release be located elsewhere. users can produce a maintenance update to the 1.0 version by modifying several source files from the 1.0 release. RCS stores Make RCS directory : files as a series of revisions that evolved from each other, as a tree. Each node in the tree represents a revision of the same file. The first version of a file creates a root. All subsequent revisions mkdir RCS form a trunk. A branch occurs when a single revision forms more than two revisions. The latest version of both branches and trunk Create a sample program file called testrcs.sas with a header is called a head. Branches are used to maintain parallel versions containing some of the keywords: of the same file. These versions may be then merged together. RCS can automatically update information, including program /******************************************* name, author name, revision number, creation time and date within a program itself. A programmer does not have to worry Program: $Source$ about updating comments in a program since RCS does it automatically. This is arguably one of the best features of RCS. Version: $Revision$ Please note that source control systems are good tools for Date: $Date$ controlling all sorts of files, not just source code. Script, flat ASCII Programmer: $Author$ files, logs or output files can be controlled by using RCS as well. ------DO NOT MODIFY ABOVE THIS LINE ------ THE FLOW OF A PROGRAM USING THE RCS SYSTEM Project: Ax14723 Platform: UNIX Purpose: Print all patients in dataset demog First Draft Requirements: N/A Production t10_25.sas Check Parameters: N/A Version Version 1.1 -In t10_25.sas Macros: N/A RCS Version 1.1 Formats: N/A Library Put Read-Only into Input: N/A t10_25.sas Check Production Output: N/A Version 1.2 -Out Check Back Assumptions: N/A In Invocation: N/A Modify Program ------DO NOT MODIFY BELOW THIS LINE ------ Modification History: $Log$ Figure 1.