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.