DAWorldAdministrationDoc.tioga
Bertrand Serlet, October 29, 1986 11:24:22 am PST
DA Software Management
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
DA Software Management
Le Changement Dans La Continuite
Mike Spreitzer
Bertrand Serlet
© Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: This document describes the DAWorld software management rules. It is mostly an edited versage of a message from Mike Spreitzer.
Created by: Bertrand Serlet and Mike Spreitzer
Maintained by: Bertrand Serlet <Serlet.pa>, Mike Spreitzer <Spreitzer.pa>
Keywords: DATools, Software Management, Release, DF Files, Version Maps, Changes Tracking, Rules, Locks, User Profile, MakeDo
XEROX  Xerox Corporation
   Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, California 94304

For Internal Xerox Use Only
1. Version Maps
To make use of the version maps for the DAWorld software, make sure your user profile entries include the DAWorld version maps:
VersionMap.SourceMaps: ... /DATools/DATools6.1/DAWorldAdministration/DAWorldSource.VersionMap
VersionMap.SymbolsMaps: ... /DATools/DATools6.1/DAWorldAdministration/DAWorldSymbols.VersionMap
Updating the version maps is done as part of the release procedure, described below.
2. Release Rules
Safety
This paragraph describes a set of rules that allow multiple implementors to work in tight coordination on a fast moving set of packages. We divide these rules into two classes: those everybody must follow, in order to not do serious damage, and those that can be followed less rigorously and at a more leisurely pace, because they are only intended to help convergence. This "safety" section covers the rules that must be followed.
The primary danger we protect against is losing source information. The source information of package Foo are the source files in it, and what Foo.DF says about those source files. We achieve this protection by locking. The locks and the dependency graph are on the physical whiteboard outside Rick's office. The locking notation is:
intent-to-write lock: red initials by Foo
Observe the following rules:
(I) If you are going to change the source information of Foo, you must:
1 - Acquire an intent-to-write lock on Foo. Go to the whiteboard outside Rick's office. You can take this lock iff there are no red initials by Foo. To take it, write your initials next to Foo in red.
2 - BringOver Foo. Forgetting this step is the biggest cause of grief known to Man. It has been the cause for the few cases of release problems observed in the last year.
3 - Do your editing.
4 - Check that your package MakeDoes.
5 - Check that the "Global Lock" is free, to prevent other people to SModel your package during that time.
6 - SModel & Verify Foo
7 - You may now release your lock on Foo.
(II) If you are going to SModel Foo, but not change source information (e.g., recompile only), you must:
1 - BringOver Foo. Again, don't forget this part.
2 - work on Foo.
4 - SModel & Verify Foo
(III) If you BringOver Foo, but will not SModel Foo (at least not untill after a later BringOver (of all of) Foo), you do not have to worry about locking.
(IV) It is always safe and permitted to do a Delete Keep 2 of anything covered by the whiteboard.
Automatically Tracking Logical Additions: The Release Procedure
Often the changes made to a package are only logical additions. This means that clients need do no more than recompile and rebind and such in order to track those changes. We have a procedure for doing this automatically. It replaces (actually, augments) steps 5 & 6 of procedure (I):
5 - Take the global lock, to notify people that you might SModel their package, and that they should not do so for the time being.
6 - Execute the command tool command "Release Foo". This command brings into ///commands/ all the release software, SModels and Verifies Foo, does a Bringover-MakeDo-SModel-Verify for each dependent package, and recomputes new version maps. You should check that the command finishes properly. When something fails, the cause is usually pretty obvious from the log, and you should correct it (following the rules, of course!) as soon as is reasonable. The "Release" command takes a very long time.
The "Release" command is established by an alias, which should go in your CommandTool.PerLogin user profile option:
Alias Release Source [DATools]<DATools6.1>DAWorldAdministration>DAWorldRelease.cm
3. DAWorldMap
DAWorldMap.df is the root of the world used to compute the VersionMaps and to track changes. If you make any addition, be very careful: take the lock before modifying DAWorldMap.df, do not add packages that could introduce circularity, do not add packages that do not MakeDo-Verify, never SModel or BringOver DAWorldMap.df, make additions with the same format.
To allow designers use the command "BringDAUser" (found in DAUser.df), when a new DF file is created, one should add it to [DATools]<DATools6.1>Top>DAWorldMap.df in an Include statement.
There is in the beginning of the df file a line to help copying the modified file to the server.