Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!mit-eddie!apollo!joelm From: joelm@apollo.uucp (Joel Margolese) Newsgroups: comp.sys.apollo Subject: Re: DSEE Benefits / Converting to DSEE (long) Message-ID: <35cd8d38.86ca@apollo.uucp> Date: Wed, 1-Jul-87 13:58:00 EDT Article-I.D.: apollo.35cd8d38.86ca Posted: Wed Jul 1 13:58:00 1987 Date-Received: Fri, 3-Jul-87 00:40:17 EDT References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> <35afc9e0.b0a1@apollo.uucp> <1938@zeus.TEK.COM> Reply-To: joelm@apollo.UUCP (Joel Margolese) Organization: Apollo Computer, Chelmsford, MA Lines: 152 In article <1938@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: > 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. 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. If you are working on a specific project, the project may have a thread such as: -reserved /sr9.5 -when_exists [sr9.5] -when_exists [sr9.0] Which says: give me the latest version of anything on a branch names /sr9.5, or give me a version named [sr9.5], which is a fixed name, or just give me the version that was used in sr9.0. The selection is done by first match. i.e. element foo[1] bar[1] fred[1] foo[2] bar[2]->bar/sr9.5[1] fred[2][sr9.5] foo[3][sr9.0] bar/sr9.5[2] bar[3] For element foo we select version 3, for bar we select bar/sr9.5[2] and for fred we select version 2. Note that I never change my thread again for the life of the project, nor do I have to know what versions change or have to maintain separate development directories. >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 > > 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. The release contains a description of what versions were used to build the object and all of its subcomponents. (It can contain more, but that is all we bother to save.) Note that we do NOT snapshot binaries. All you need is the description of how to build anything and the binaries are regenerable if they happen to get flushed out of the pools. If the baselevel is used as a reference point, the binaries stick around, if not, say as the baselevel ages and becomes obsolete, the binaries get flushed out of the pool automatically. Therefore the cost of a baselevel (release) is very low. (a few disk blocks.) To build off of such a baselevel the thread just needs to say: -reserved (if you want this) foo!/release/pathname -versions > 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 developpers who want to stay in sync. > 3) Release your private changes to the world, making your next build be > strictly "top of trunk". > Answered above, I think. >All these functions are of course quite easy using our existing system. Our experience here (which does not necessarily apply everywhere) was it was no easier for just doing mainline development under dsee, but once you started doing anything in parallel, or wanted to experiment with versions DSEE became invaluable. It is the old story: You don't miss it until you've tried it and lost it. > >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. 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. > > 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 > 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? DSEE does not (in general) have a server. There is a d3m server which runs on nodes that have DSEE libraries, d3m is the database manager. DSEE also uses the alarm_server (which runs on most nodes anyways) as a way of sending some notifications. (One of the possible monitor actions is to send an alarm to somone that some element has been modified or whatever.) DSEE itself can run as a server and will then accept input via mailboxes. This of course works across the network the same as on individual nodes. This allows you to design a custom interface or a set of shell level commands or whatever to communicate with DSEE. Most DSEE functions are also available via a released (*some* things get released! :-)) set of calls to the dseelib global library, so you could write your own server if you really want to. I am not a DSEE developper, just a heavy user who likes to tell people about neato things they can do by moving up to newer tools. (Ok, so I'm biased, why not?) Joel -- Joel Margolese UUCP: ...{attunix,uw-beaver,decvax!wanginst}!apollo!joelm Apollo Computer ARPA: apollo!joelm@eddie.mit.edu INTERNET: joelm@apollo.com