Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!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: <1938@zeus.TEK.COM>
Date: Mon, 29-Jun-87 22:33:16 EDT
Article-I.D.: zeus.1938
Posted: Mon Jun 29 22:33:16 1987
Date-Received: Sat, 4-Jul-87 18:39:32 EDT
References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 74

Thanks for the exposition about DSEE, Kee.  It's clear that DSEE can handle
the source parallax problem I previously described.  I still like the system
we have with Make and RCS better.  We buy convenience, and pay for it with
disk space.

From your explanation, I see that the difference between the two systems is
that where we have an implicit selection of version by choosing which
source/object pair is sitting in our individual development directory, the
canonical approach in DSEE is to maintain an explicit enumeration of all the
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.

Not being a DSEE user, I can only speculate on how well this works, but if
you have a complicated system with many (say a hundred) source files and
many (say more than 5) developers, either the threads must get quite
complicated or a lot of time is spent assigning new version numbers to the
tops of trunks of all the components.  Do you find either of these fit your
operating environment, and do either of them pose a problem?  Do you have
any mechanism which automatically updates your thread to adjust the build
for:

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

    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,

    3) Release your private changes to the world, making your next build be
	strictly "top of trunk".

I suspect such a utility should be possible, though it would probably
require a lot of global version number assigment to manage the bookkeeping.
All these functions are of course quite easy using our existing system.

We do pay other penalties for our approach.  Since we have separate copies
of binaries, we get a lot of duplication in compilation.  Include file
changes can propogate a lot of identical and unnecessary build steps.  Most
people have cheater scripts that do a simple compile and link for making
small changes to the system, and periodically these scripts must be updated
to reflect the new set of components and compile time options required to
build the system.

    Basically there are two kinds of monitors.  One executes arbitrary
    commands when you perform a specified action (e.g. send mail to everyone
    telling them that a file has been checked in).  The other adds "tasks"
    to a "task-list".  I'm not going to go into any detail on that, since
    I've never used it.  The basic idea is that you can set up a task list
    of things to do, and the act of checking a file in or some similar
    action can be made to trigger a task which will remind you of what you
    have to do next.  As it turns out neither of these use a server, both
    are executed by DSEE at the time you perform the action.

Okay, so the server is not used for notification.  I've heard that DSEE does
have a server.  Why?  What functions DOES it perform?

    A "builder" is the machine ("node") on which the compile ("build")
    actually takes place.  What DSEE allows you to do is give it a list of
    up to 20 different machines which can be used to build things.  Since
    DSEE has a clear idea of who depends on what, it knows which things can
    be built in parallel and which must wait for the results of some other
    build.  It then spawns off each task to a different machine.

I've been intrigued with this sort of facility since I first heard it
described a year or more ago.  A friend who works at Sequent described their
"parallel Make" which takes (mostly) a standard makefile and performs the
same function.  Unfortunately, we have no such facility here.  (As Apollo
migrates towards a more UNIX-like SR10, it would be great if they built a
similar function into the Make they provide :-)
-- 
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK