Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!tektronix!teklds!zeus!bobr
From: bobr@zeus.TEK.COM (Robert Reed)
Newsgroups: comp.sys.apollo
Subject: Re: DSEE Benefits / Converting to DSEE (long)
Message-ID: <1952@zeus.TEK.COM>
Date: Thu, 2-Jul-87 16:03:13 EDT
Article-I.D.: zeus.1952
Posted: Thu Jul  2 16:03:13 1987
Date-Received: Sat, 4-Jul-87 09:47:48 EDT
References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp> <1938@zeus.TEK.COM> <35cd8d38.86ca@apollo.uucp>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 90

In article <35cd8d38.86ca@apollo.uucp> joelm@apollo.UUCP (Joel Margolese) writes:

    > versions which comprise a particular "build" of the system.  Where we just
    > copy a new source file into our development directory, the DSEE approach is
    > to edit the "thread" to redefine the configuration through explicitly named
    > releases of system components.

    You only need to edit a thread when you want rebuild a particular
    version of something or select (and lock) the versions that you use.
    The "default" thread is:
     -reserved
     []

    Which means, any element that I have reserved or the most recent version
    of all other elements.  Therefore, whenever any source files are
    replaced, (or "put back into your development directory") they will be
    picked up.  Since that behaviour is what most people (around here
    anyways) seem to want most of the time, it just works.

This simplified approach of course breaks the scheme that Kee so carefully
outlined to isolate simultaneous source modifiers from partial release side
effects, and so it doesn't answer the question I was posing.


    > 1) Sealing your particular set of versions to prevent such side effects
    >    as have been described,

    We periodically take make baselevels.  To do this an administrator will
    take a snapshot by building the object (assuming that it is tested,
    stable whatever) and creating a release.

Perhaps I failed to explain myself adequately.  Perhaps you failed to read
the discourse between Kee and myself.  In any case, I don't believe you
understand my questions.  The members of our engineering group have
interchangable responsibilities for code and so operate in an environment
where it is desirable to allow multiple simultaneous reservations for
sources.  One of the side effects of such an environment is a sort of update
parallax error, where the simple priority scheme you outline for determining
which version to use just won't work.

    > 2) Incorporating changes made by other developers, performing source
    >	level merges where necessary, while preserving your changes as
    >	nonreleased reservations to prevent possibly buggy development code
    >	from reaching other developers,

    DSEE also provides quite a good 3 way merge system, (vastly improved:
    i.e. now usable) at version 3.0) that does source level merges.  It does
    not work that well if the changes are *really* extensive, but for
    routine changes, it generally does the whole merge automatically.  (And
    usually gets it right!) Because of the history files, DSEE can see the
    common ancestor and the two changed files and figure out which file
    changed what.  It only asks for your help if both versions changed the
    same code, then you get to pick which version you like better, or edit
    it yourself.  It also keeps track of what has been merged, so that if
    you change 30 modules you can say something like:

     show elements -missing -merge -with foobar

    The changes are not replaced until the developer issues a replace
    command.  This is useful for several developers who want to stay in
    sync.

These seem on par with the facilities available through RCS.

    > We do pay other penalties for our approach. ...

    This sounds like much more work that we do to keep track of the correct
    thread, and a lot more error prone.  DSEE also gives us the ability to
    look at a build in a DSEE pool and determine exactly what versions of
    each file were used so that we can have a high degree of confidence in
    what we've built.  DSEE also allows you to declare "equivalences", it
    means saying: I've just changed foo.ins.pas, and there are 72 modules
    that depend on it.  But I know that that only 3 need to be rebuilt.  For
    all the others, assume that foo.ins.pas[3] is equivelent to
    foo.ins.pas[2].  Specifing that is not very hard, DSEE will prompt you
    for everything.

No, there is very little work involved since the list of linker modules
changes very infrequently these days, and when it does, there is a file
which always has the proper list, so editing involves deleting the old list
and incorporating a new one.  I do that once every couple of months.  The
equivalency notion of DSEE sounds intriguing.  Do such equivalencies ever
get obsoleted?  Are they easy to keep track of?  Are they based on analysis
or hunch?

This has been a great discussion.  Unfortunately (or fortunately), I'm going
on vacation for a couple of weeks, and so will have to drop out now.  See
you when I get back.
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK