A mechanism to support parallel development via RCS

Hewlett-Packard Journal, June, 1991 by John W. Goodnow

AT VARIOUS INTERMEDIATE checkpoints during the product development life cycle, it usually becomes necessary to stabilize the software for event such as field trials and finanl functional verification. A conflicting, but equally important requirement is that development for future checkpoints and releases must be allowed to continue while baseline* software is kept stable. At HP's Imaging Systems Division (ISY), the need for this parallel development is also driven by continuous field trials and frequent software upgrades. ISY produces realtime embedded systems software for the control of ultrasound instruments (primarily diagnostic cardia imaging). A typical instrument consists of several subsystems, which range in size from 700 source files totaling 60 KNCSS** to 1200 source files totaling 200 KNCSS.

This article describes a simple mechanism, based on the HP-UX platform and the RCS (revision control system) utility, for effectively achieving parallel development capabilities and implementing baseline configuration management. The mechanism described is reliable, robust, and simple to use and administrate. It is widely used by the software development groups at ISY.

Although the parallel development mechanism described here can be integrated with almost any software development environment in which RCS is used, the implementation at ISY is based on an in-house software development environment built over the last four years. This underlying environment, hereafter referred to as the ISY SDE, or just SDE, runs on a distributed network of HP 9000 Series 300 workstations and uses RCS and nmake to realize revision control and build management. To understand the workings of the parallel development mechanism, it is important first to understand the major underpinnings of the ISY SDE.

The ISY Software Development Environment

The ISY SDE is essentially an extensible directory structure and a rich set of support tools that provide the development group with revision control and build management. In addition, support is provided for independent private development, in which individual software engineers can link local copies of modules under development with stable baseline software.

Directory Structure. In general, a particular instance of the ISY SDE is rooted at a directory consisting of three logical components: the super root, the name, and the revision. For example, in the SDE rooted at /users/prism/main, the super root is /users/prism, the name is dss, and the revision is main (see Fig. 1). Each instance of the ISY SDE has an area for source (and header) files under RCS control as well as a separate area in which individual software engineers can keep local, working versions of any of those source files (work directory in Fig. 1).

Revision Control Based on RCS. As stated above, the revision control aspects of the ISY SDE are handled by RCS. Without considering parallel development, the use of RCS in the SDE is quite straightforward. The SDE contains a large body of source files, all of which are under RCS control. At any given time, the latest revisions of these files make up the mainline configuration. For projects in the ISY development lab, the mainline usually corresponds to unreleased software in various stages of development.

During the course of development, software engineers can check out mainline files, modify these files, generate and test executable software based on these modifications, and check the files back in. These modified files become part of the mainline when they are checked back in. These operations are the standard checkout (co) and checkin (ci) RCS commands.

Build Management Based on Nmake. The ISY SDE uses the nmake program to manage the build process. Nmake is very similar to the standard make program, but it is substantially more flexible. For example, nmake automatically evaluates and mainains dependencies introduced by header files.

For a typical ISY project, the mainline is always built nightly, and is rarely, if ever, built during the day. This is because the build process takes several hours to complete. Building the mainline during work hours not only leaves the project's object files in an inconsistent state for long periods of time, but also introduces unacceptable loading on the workstations executing the build.

Standard Directory Types. The source files that make up the mainline of the project are stored in a hierarchical directory structure. This ensures that each source directory contains a set of functionally related files, and no directory contains an excessive number of files. Header files are kept in a global header directory or in individual source directories according to their scope.

Although the hierarchy and allocation of source files to directories are arbitrary and completely at the software engineers' discretion, the organization of an individual source directory is highly structured. This structure is imposed by the SDE, and it exists to strike a good balance between the capabilities provided and ease of use. A source directory with this SDE-imposed structure is called a standard directory.