http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.575....
Excerpts:
"DSEE is implemented as one program, with instances running at various nodes in the network."
On the history manager:
"DSEE can create a shell in which all programs executed in that shell window transparently read the exact version of an element requested in the user's configuration thread. The History Manager, Configuration Manager, and extensible streams mechanism (described above) work together in this way to provide a "time machine" that can place a user back in a environment that corresponds to a previous release. In this environment, users can print the version of a file used for a prior release, and can display a readonly copy of it. In addition, the compilers can use the "include" files as they were, and the source llne debugger can use old binaries and old sources during debug sessions. All of this is done without making copies of any of the elements."
On the configuration manager (sounds like system wide built artifact caching):
"The CM maintains a derived object pool which holds several version of each object that was produced as the result of building a component named In the system model (e.g., binaries). Each derived object in the pool is associated with the ECT used to build it. When asked to build, the CM determines a "desired" BCT by binding the system model to the versions requested by the user's current CT. The CM then looks in the derived object pool to see If there ls a BCT that exactly matches the one desired. If a match is found, the derived object associated with that BCT is used. Otherwise, the component is rebuilt In accordance with the desired BCT, and the new derived object and BCT are written to the pool. In all cases, the user is given exactly what he asked for."