DSEE: a software configuration management tool

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

DSEE files are type case[underscore]hm. When asked to read a pathname that ends with a DSEE file's name, the case[underscore]hm type manner returns the most recent version on the mainline. If the user wants to read some other arbitrary version, the version can be explicitly named or implicitly associated with the original file. If the pathname continues beyond a DSEE element, the case[underscore]hm manager interprets the remainder of the pathname as a sequence of branches and generations. This extended naming does not work across all transparent remote file systems. Some remote users have to use the DSEE fetch command, which refers to versions with a similar syntax. All users can use the read command, which puts any version into a read-only X11 window.

The following examples, which are derived from Figs. 1 and 2, illustrate the different type of pathnames that are used to access different versions of modules in DSEE.

* Most recent version of the main line of descent foo.c

* Specified version number on the main line of descent foo.c/193

* Most recent version on the specified branch foo.c/v3.3bugfix/brezak1

* Specified version number on the specified branch foo.c/v3/3bugfix/2

* Specified version name foo.c/v3.3bugfix[v3.3.2.alpha].

Users can also implicitly refer to a collection of versions, like those used to build some binary, or a specific named version of each of their files. In Domain/OS, the user can create a shell that is bound to that collection. Whenever files are read from that shell, the case[underscore]hm manager will access the particular versions that had been specified.

In the case where DSEE files are accessed from a non-Apollo computer, the mechanism that binds versions to shells does not work across most transparent remote file systems. Therefore, the user has to access the desired files through a special directory whose presence indicates the version the user wants. In the following example, vq6cro6b is such a directory. Requests to read below it are handled by the vswitch type manager, which reestablishes the versioning context and then hands the request on to the case[underscore]hm type manager.

Domain/OS pathname:

emacs/fireball/mylibrary/utils.c

HP-UX pathname:

emacs /apollo/zorro/sys/nodedata/tmp/vq6cro6b/mylibrary/utils.c

When emacs on HP-UK opens

apollo/zorro/sys/nodedata/tmp/vq6cro6b/mylibrary/utils.c,

the request is passed to the HP-UK operating system. HP-UK recognizes that /apollo is an NFS mount point and issues a series of NFS requests that should result in the desired file being opened. Eventually, the remainder of the pathname

zorro/sys/nodedata/tmp/vq6cro6b/mylibrary/utils.c

is passed to the Apollo NFS server which submits the request to the Domain/OSI/O system. When the I/O system encounters the object vq6cro6b, which is file type vswitch, it loads the vswitch type manager. The vswitch type manager uses the rest of the pathname and information stored in the vswitch object to establish the proper versioning context, and then passes the request to the case[underscore]hm type manager.