Content provided in partnership with
Thomson / Gale

FIND IN Advanced
Search

DSEE: a software configuration management tool - Domain Software Engineering Environment


THE DOMAIN SOFTWARE Engineering Environment (DSEE) is a configuration management system that is useful for managing large, complex software development and maintenance projects. (*) DSEE runs on the Apollo Domain operating system (Domain/OS) and is in use at over 6000 sites world-wide, including HP Apollo. We estimate that DSEE is responsible for managing over one billion lines of code. DSEE is also encapsulated in the new Softbench (1) technology.

DSEE is designed to deal with the particular problems of large-scale software development. Some of these problems are working on multiple development efforts in parallel, maintaining existing releases while working on new code, coordinating code and documentation, reducing the time it takes to build a program, and knowing precisely which tools and versions of source code were used to create a binary file. DSEE unifies development and maintenance for large-scale systems (the largest so far is 11,000,000 lines). It supports project development in a distributed computing environment, and works with any programming language or tool. DSEE is highly reliable, thanks to transactional file and database operations, store-and-forward message passing, audit trails, and time-proven fault recovery procedures. The latest version of DSEE, version 4, makes the configuration management capabilities of DSEE available to a variety of non-Apollo systems.

The major subsystems that make up DSEE include:

Advertisement

* History Manager. The history manager stores, controls and tracks source code evolution, and enforces concurrency ontrol.

* Task Manager. The task manager plans and tracks the low-level steps taken toward achieving some high-level activity--for example, tracking the modules changed to implement a new feature.

* Monitor Manager. The monitor manager tracks people-oriented, rather than build-oriented dependencies. For example, it notifies users when alarms they set are triggered because components of interest are modified.

* Configuration Manager. The configuration manager is concerned with system building. It also manages derived modules such as binary files or formatted text.

* Release Manager. The release manager archives executable, and optionally, it can take a snapshot of the tools, elements, and files used. An element is a file under DSEE source control.

This article provides an overview of these subsystems. There is also a discussion of DSEE version 4 features that allow non-Apollo users to have access to DSEE capabilities.

Version Control

The history manager stores, controls and tracks source code evolution. It enforces concurrency control and security, and keeps a complete chronological audit trail of library modifications. DSEE views the evolution of a file as a directed acyclic graph (see Fig. 1). Any number of people may work on the same file concurrently by making new branches. Their work may be kept separate or merged together with a three-way merge command (Fig. 2). The trunk is also considered to be a branch, and it is usually referred to as the mainline.

In merging versions on two branches together, DSEE compares the two versions with their nearest common ancestor. If work in a small section of the file changed one branch relative to the ancestor--and didn't change the equivalent location in the other branch--DSEE automatically selects the new modifications. If both files have changed relative to the ancestor, DSEE presents both sets of changes in a window. Users may pick one or both sets of changes, which are then copied to a window containing the merged file. The user can further edit the file in the merged window. Fig. 3 shows the DSEE screen during a merge operation.

Branches have names like v3.3.bugfix or AddBuzzwords. Versions or generations on a branch have version numbers, but can also be given one or more names (e.g., version 1 of v3.3.bugfix in Fig. 2 has four names). The evolution of a module can get very complicated. That's why DSEE has a command called show derivation that allows the user to display graphically the structure of a module's evolution, including branch points. Figs. 1 and 2 without the callouts are examples of what the show derivation command provides. The show derivation command also has options to prune portions of the displayed structure.

Versions are stored together efficiently. DSEE's inter-leaved forward deltas and compression allow 50 to 200 versions of source code to be stored in the same space as two ordinary text copies. Binary files can be stored under DSEE, but they are not stored as compactly as text files. Any version of either text or binary files can be read in a single pass through a DSEE history file.

Transparent Access to Versions. Because of the Domain operating system's typed file system, (**) any DSEE element can be read directly, without checking it out from the library, either from an Apollo system or across a transparent remote file system like NFS, DECnet, or Domain/PCI. This lets ordinary applications like cc and troff operate on objects under DSEE control without modification.

1 -  2 -  3 -  4 -  5 -  6 -  7 -  Next