Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!apollo!nazgul From: nazgul@apollo.uucp (Kee Hinckley) Newsgroups: comp.sys.apollo Subject: Re: DSEE Benefits / Converting to DSEE (long) Message-ID: <35afc9e0.b0a1@apollo.uucp> Date: Thu, 25-Jun-87 15:55:00 EDT Article-I.D.: apollo.35afc9e0.b0a1 Posted: Thu Jun 25 15:55:00 1987 Date-Received: Sat, 27-Jun-87 03:07:54 EDT References: <3596c60e.b0a1@apollo.uucp> <1907@zeus.TEK.COM> Reply-To: nazgul@apollo.UUCP (Kee Hinckley) Organization: Apollo Computer, Chelmsford, MA Lines: 186 In article <1907@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: > to a common RCS directory. We have the option of including updated sources > for a particular make or not, which allows us to isolate ourselves from the > changes of others. I would be concerned with a system that uses common > binaries which did not provide this isolation. If a member of the team > releases a change which involves several binaries, one or more of which I am > also making changes to, is there some way to automatically prevent the > incorporation of the rest of the binaries involved in this change? > > For example, if a system consists of modules a, b and c, suppose someone > else has checked out b and c when I proceed to check out b. I begin to make > and test changes to b, but suddenly a new version of b and c are released to > the world. If these foreign changes to b and c are dependent on one > another, is DSEE flexible enough not to include the new object for c in my > subsequent builds of the system? My guess is that since I have not checked > out c, I would get the common version, which may mean that my bind will fail > (if for example, my version of b had a vestigial external reference, > formerly resolved by c). Good question. I'm having a little trouble explaining things today, so bear with me, this is probably a bit longer than it need be. Presumably you checked out B by making a branch off the mainline (since the other person already had the mainline reserved). (Alternatively of course they may have made the branch and you have the mainline, it doesn't really make any difference to this issue.) In your thread you can specify any number of constraints. The default is simply to take any reserved files it finds in the current directory, and then to take the most recent version of the common stuff. If this is the case then you won't run into any problems until someone changes something in the mainline that you depended on. In the case you describe if the new versions of B and C are off on a branch then you don't have to worry, you'll never see the binaries. On the other hand if they are in the mainline (or have been merged back into it) you could have problems. The way to avoid this problem is to specify in your thread what version of the common files you want to use. I think this is probably best explained by an example: Here's what exists now (bracketed items are version numbers): a[1] -> named SR9.2 a[2] -> named SR9.5 b[1] -> named SR9.2 and SR9.5 c[1] c[2] -> named SR9.2 c[3] c[4] c[5] -> named SR9.5 Now, P1 and P2 or both doing development based on SR9.5. So your threads look like this (we try and make sure that everyone working on a project uses the same base thread so we know exactly what's going into the things we release): -for ?*.c -reserved -use -g -reserved -for ?*.c -use -O [sr9.5] -when_exists [] Read in order that says that: o All reserved C files are compiled with "-g". o Any other files that are reserved are also used. (If we took out these two lines then we wouldn't use any reserved versions at all, useful when you want to make a pure release without including the stuff you are currently working on.) o All non-reserved files are compiled with "-O". o If there's a non-reserved file that has a version named "SR9.5", use that one. o Otherwise take the most recent version of the it. Okay, now P1 reserves file "b" and file "c" from the mainline to do some work. P2 comes along and wants to make a change to file "b". Since it's already reserved P2 has to create a branch, let's call it "/P2". Now P1 replaces file "b" and file "c" with changes that are incompatible to what P2 is doing. As it happens P1 names these versions, but it doesn't really matter for our purposes. Now the state looks like this (ignoring file "a"). b[1] -> named SR9.2 and SR9.5 b[2] -> named SR9.6_BL1 c[1] c[2] -> named SR9.2 c[3] c[4] c[5] -> named SR9.5 c[6] -> named SR9.6_BL1 If P2's thread hadn't had the line "[SR9.5] -when_exists" then P2 would now be getting the most recent version of "c" and would be in trouble. However as it stands P2 will continue getting version 5 (SR9.5) of "c" and will still be getting the reserved copy of "b". So everyone's happy. Now let's take the scenario a little further. P2 decides to check "b" back in, but not to merge it into the mainline yet since it still needs some testing. Now the state of "b" looks something like: b[1] -> named SR9.2 and SR9.5 b/P2 b[2] -> named SR9.6_BL1 Now if P2 wants to specify that in P2's compiles that branch is always used, the thread has to be changed to look like: -for ?*.c -reserved -use -g -reserved -for ?*.c -use -O /P2 -when_exists [sr9.5] -when_exists [] Note that because of the order the "/P2" branch will be used whenever their might be a conflict between "/P2" and "[sr9.5]". And all throughout this there will still be no confusion between the binaries. In fact, since DSEE knows what compile options were used, it won't even confuse binaries that have different compile options, so if you specified that all non-reserved binaries were also compiled with "-g" you would only get those common binaries which had been compiled with that option. > Change notification is certainly a useful service in a multi-person project. ... > deny that it may have some use. Providing a server for that purpose does > seem a bit of overkill (I am assuming that this function is handled by the > DSEE server), so I hope the server has more purpose than simple notification. I had to run off and ask about this one. 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. (You can also specify whether a monitor is to be executed for everyone, just for you, or just for everyone else. And obviously there are protections concerning *who* can create monitors.) > I don't understand what you mean by "multiple builders." Is it something Sorry, I should have explained the terminology. 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. Two things make this even more useful. First of all it checks the load on the machine and won't use it unless it's relatively idle. That way you seldom notice that someone is using your machine for a build. Occasionally you will notice if you start something while a build is underway, but DSEE checks for activity before each individual build, so once the current task is done it won't come back until your node is idle again. Secondly it allows you to specify a reference pathname which the "/" directory will resolve to. In other words, if my model makes references to tools in "/bin" and sources in "/usr/nazgul/src" I don't have to worry about whether the tools are the same on other machines, or whether the pathname (or link) "/usr/nazgul/src" exists on the remote machine. As far as the remote process is concerned the directory structure looks like my machine. That means I don't have to specify absolute network pathnames anywhere and then worry about what happens if I change the name of my machine or move the sources somewhere else. All of this is done automatically, so long as you somewhere tell DSEE what machines to use. For instance, here's the line from my dsee startup file. set builder -reference //morgul //anarres //morgul //faerie //caruso //northpeak //marvin That tells it that the reference machine (to which "/" will refer) is mine ("//morgul") and that when doing builds it should look for CPU time on "//anarres", then my node, and then the others, so on down the line. (Actually, looking at this I just realized that I only have 6 builders listed, I think I'm going to go hunt down some more fast machines. :-) .... And THAT is more than enough about DSEE for now. Hope it helps. Kee Hinckley User Environment -- UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.