DSEE: a software configuration management tool

Hewlett-Packard Journal, June, 1991 by David c. Lubkin

1. For each file used in the system, if it is reserved, use the version in the working directory.

2. Otherwise, use the version named V2 for each file (version 3 from beta and version 8 from alpha).

There is also a model thread that applies to system models. Model threads are usually stored within a DSEE library so that users have a precise description of the structure of a program at any time in its history. They are often composed of several files, or model fragments. The model thread describes which versions of model fragments and conditional compilation options (targets) to use when interpreting the sytem model. One use for targets is to switch between different hardware platforms or operating system versions. At Apollo, the system model for the Domain/OS operating system supports over a dozen different hardware variants.

Bound Configuration Threads. DSEE combines the system model and configuration thread to make a bound configuration thread (see Fig. 4). It is a permanent record of the options, versions of sources, and tools used to build a component. Bound configuration threads are kept along with derived objects and binaries in special directories called pools. When the user types build, DSEE looks in the pools for bound configuration threads that match the components the user asked to build. DSEE keeps a number of earlier builds in the pool and attempts to reuse them. If it can't, and the pool is full, the least recently used build of that component is purged to make room for a new one. This lets the users share binaries, thereby reducing the number of builds to perform. On the other hand, because the bound configuration thread gives such a clear picture of what makes up a particular binary, only binaries that match the users' needs are shared.

DSEE lets the user declare that some compiler options or source versions are critical and that others are noncritical. If a critical dependency changes, DSEE will rebuild the module. If a noncritical dependency changes, DSEE will record what compiler option or source version was used, but it will not rebuild the module. There are also override mechanisms through which the user can force DSEE to rebuild even though the bound configuration thread doesn't call for a build, or not to build when DSEE thinks it has to.

Before DSEE starts building it sequences the required builds according to their interdependencies. As the user's translation script executes, it reads the desired version of each DSEE element directly out of its library. After the program is built and debugged, the user can make a release, or permanent snapshot of the bound configuration threads, binaries, sources, tools, and system model that make up the program. With this feature, when customers report a bug two years, the engineer repairing the code can rebuild the same bits, plus the fix.

Version 3 of DSEE added support for parallel building on more than one Apollo computer at the same time. DSEE tracks the CPU utilization of candidate build computers, and start builds on the most lightly loaded machines. Fig. 6 shows parallel builds running on several machines. The performance improvement provided by parallel building can be substantial. For example, the time to run the Ada validation test suite drops from 80 hours to 17 hours when it is built in parallel.