DSEE: a software configuration management tool

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

Configuration Management

The central concern of DSEE configuration management is to provide a reliable and complete permanent record of what sources, tools, and translator options were used to build a program. This is one of the primary characteristics that distinguishes DSEE from other configuration management tools. DSEE uses this precise description to improve personal and group productivity, but never at the expense of correctness. Users can share binaries with each other when the descriptions of what they want to build match. Their work is kept isolated when they don't match. DSEE will minimize the number of compiles required to build a program and how long they take.

The configuration manager separates the descriptions of the structure of the user's program (i.e., the system model) and the specific versions the user wants to build at a particular time (i.e., the configuration thread).

System Models. A system model is a set of files that describe the static structure of a program or system. It is written in a special declarative and block-structured language. System model components may either be DSEE elements or external, nonelement files. For each component of the system, the model expresses:

* Source dependencies (i.e., what the source includes)

* Translation rules (*) (i.e., how to compile the component)

* All possible translation options (e.g., -debug, -opt)

* Tool dependencies (i.e., tools required for the translation)

* Subcomponents that must be built first.

The model language supports conditional constructs that may be triggered by target system characteristics.

A utility is provided with DSEE to help the user create a system model. It determines the include file interdependencies by looking at the source code and creating a skeletal system model. The user will still have to tell DSEE how to build the program and fine-tune the model. Fig. 4 shows a small portion of a system model description.

Threads. Configuration threads describe which versions and translator options to use when building each component in the system model (see Fig. 5). By changing threads, users can quickly switch among new development projects, fixing bugs in old releases, and making special versions for particular targets or customers.

Configuration threads may be:

* Explicit (e.g., use version 5)

* Dynamic (e.g., use the most recent version)

* Referential (e.g., use the same version used in rev2)

* Contextual (e.g., use x.h[7] for P, otherwise x.h[6]).

Fig. 5 illustrates how two engineers can build similar, but not identical configurations of the same system by using different configuration threads. Engineer A is using a thread that tells the configuration manager to follow these rules:

1. For the file alpha, use the most recent version on the mainline.

2. For every other file, use the version named V2 (version 3 from beta and version 6 from gamma).

The mainline for file gamma is reserved in engineer B's working directory. Engineer B uses a configuration thread that tells the configuration manager to follow these rules: