Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!masscomp!ulowell!apollo!oj From: oj@apollo.UUCP Newsgroups: comp.sys.apollo Subject: Re: DSEE Benefits / Converting to DSEE (long) Message-ID: <35eb214c.d5b2@apollo.uucp> Date: Tue, 7-Jul-87 11:07:00 EDT Article-I.D.: apollo.35eb214c.d5b2 Posted: Tue Jul 7 11:07:00 1987 Date-Received: Thu, 9-Jul-87 02:18:50 EDT References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp> <35b36fa0.c366@apollo.uucp> <1745@zaphod.UUCP> Reply-To: oj@apollo.UUCP (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Lines: 164 Keywords: CASE, DSEE In article <1745@zaphod.UUCP> billj@zaphod.UUCP (Bill Jones) asked a bunch of questions about DSEE. I'm another Apollo in-house DSEE user, and fan, but I'm not a DSEE developer. Here are my answers to Bill's questions (which I've trimmed a bit): >- is there support for maintaining parallel > systems of derived objects...? Or will most of the binaries > have to be recreated on each build > as the pool cache capacity is reached? Parallel systems are supported. Different pools can be used for different variants(like debugging on and off). Options (typically, compiler options like CPU variants, debugging, optimization) can be specified as either -- "critical" meaning if the binary pool doesn't contain an an object that was made with the option, DSEE will remake it with the option. -- "noncritical" meaning that DSEE will accept the same source file, but compiled with a different options. (Note that all dependencies, including insert files, can be critical or noncritical.) "Pool capacity" means three things: (1) disk storage capacity--limited by the disk a pool is on; however, pools can be split among disks and nodes. (2) a -limit option to set the number of versions of a derived object that are retained in a pool. (3) an -age option to specify the number of hours that a derived object version must have been sitting in the pool to be a candidate for purging. We keep this just large enough to give us a chance to actually use the objects. >- what support is there for variant > implementations of the same module? Variant implementations are kept on branches in the source library. For example, I might do the following: DSEE> set library /gpr/src #to access the GPR source library DSEE> create branch sixteen text.pas #to make the branch "sixteen" for text .... edit.... DSEE> replace text.pas/sixteen #check in my branch DSEE> create branch kanji text.pas/sixteen #make a branch off a branch .... edit.... DSEE> replace text.pas/sixteen/kanji #check in my kanji branch > Must the elements be named > differently...? No, not really. Once I create and check in my kanji branch, I can read it using the path name /gpr/src/text.pas/sixteen/kanji > and the system model preprocessed...? No need to "preprocess" the system model explicitly. The configuration thread settings can be used to select which branch or version of each module get compiled when DSEE does a build. For example, one might use this configuration thread: -reserved -for vector.pas -use_options -opt 2 -for '?* @ gpr' /sixteen/kanji -when_exists -for '?* @ gpr' /sixteen -when_exists [sr9.6] -when_exists [] This means: 1. Use my reserved version of any module if I have one. In this case a module is either a source or header (insert) file. Compilations run under DSEE automatically locate the thread-selected versions and branches of header files. 2. Compile vector.pas with "-opt 2" 3. Use the /sixteen/kanji branch for any module for which that branch exists. 4. Use the /sixteen branch for any module for which that exists. 5. Use the version named sr9.6 for all modules that have such a version name. 6. For all other modules, just use the latest stuff. > can they be distinguished automatically in the directory structure? Yes. >- can a bug-fix or feature branch to several elements be treated > (e.g. named or merged) globally, or must the operations be repeated > for each element affected? I'm not sure whether branches can be created or merged globally. The branch and configuration thread system is flexible enough that there's no need to take branches of "everything," so I've never tried it. Version names can be applied either globally or module-by-module. >- can a system be composed of subsystems each maintained in its own > directory structure? Yes. This is standard practice here. A system model can refer to several DSEE source library areas. > Must there be a single system model (with > absolute pathnames) for the whole? You can have as many system models as you like. However, we ordinarily use just one for each major component, and maintain it as a DSEE element, with branches and version names. As for absolute pathnames, what we do is create a standard set of links in the root directory of each developer's node. For example, here are some of the links in the root structure of my node: dl "//id/dl" dm "//guess/what/dm" gmr "//ice/cream/gmr" gpr "//tribble/gpr" gsr "//ice/cream/gsr" os "//os/os" uet "//guess/what/uet" us "//us/us" x10 "//morgul/x" Most (not all) of these directories have a "src" and a "ins" DSEE structure under them. Thus, I (and everybody else) can find the gpr file text.pas by using the path name /gpr/src/text.pas ... this resolves, through my link to //tribble/gpr/src/text.pas . Things do change... Once in a while, somebody sends around mail saying, for example "/dm" is moving from //ice/cream to //guess/what . At the same time, they do a copy_tree ($ cpt or % cp -r) of the DSEE structures to the new node / volume, and put a symbolic link in place of the old structure. Thus, until developers make the change, they traverse an extra symbolic link. So yes, you need absolute pathnames for multiple libraries, but using links mitigates the problem. >The next few questions deal with evolutionary systems where not only >the module code, but the module structure itself may change over time. >- the extracts quoted from system models indicate that include > dependencies must be specified manually. I understand that there is > a make_model program to determine these automatically when the model > is first written, but has there been any support added to generate > them dynamically at build time? Not that I know of... but builds do succeed, with a DSEE warning message when you omit a dependency. I use this feature to "debug" my system model. Here's a transcript from a DSEE session showing this. Completed "gsr_vector.pas" on //VERMONT (6BAD) Build gsr_vector.pas!6-Jul-1987.22:34:02 ?(DSEE/Streams Manager) Element "//us/us/ins/gpr.ins.pas" was read but was not declared as an Element dependency. ?(DSEE/Streams Manager) Element "//us/us/sys/ins/gpr.ins.pas" was read but was not declared as an Element dependency. No errors, no warnings, Pascal Rev 7.2891 >- if the structure of the system is changed at some point in a way > which significantly affects the system model, will subsequent > modifications to earlier configurations see the new or old model? Models can be placed on branches, and snapshotted as part of the release-creation process, so the answer is that modifications see the appropriate model. >My thanks to the long-suffering correspondents at Apollo for any >answers they can provide. Thank you for reading this far. This turned out to be sort of long. Ollie Jones. Apollo Computer. I'm responsible for my own statements and misstatements. My knowlege of DSEE comes through (a) using it and (b) reading the published manuals.