Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/unix/volume19/shape/part31

Text File | 1989-05-31 | 52KB | 1,354 lines

Subject:  v19i044:  A software configuration management system, Part31/33
Newsgroups: comp.sources.unix
Sender: sources
Approved: [e-mail]

Submitted-by: Axel Mahler <unido!coma!axel>
Posting-number: Volume 19, Issue 44
Archive-name: shape/part31



#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#        "End of archive 31 (of 33)."
# Contents:  papers/boston.ms
# Wrapped by [e-mail] on Thu Jun  1 19:27:20 1989
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'papers/boston.ms' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'papers/boston.ms'\"
else
echo shar: Extracting \"'papers/boston.ms'\" \(49291 characters\)
sed "s/^X//" >'papers/boston.ms' <<'END_OF_FILE'
X.de Mc
X.nr L1 \\n(LL*10/21
X.if \\n(.$ .nr L1 \\$1n
X.nr NQ \\n(LL/\\n(L1
X.if \\n(NQ<1 .nr NQ 1
X.if \\n(NQ>2 .if (\\n(LL%\\n(L1)=0 .nr NQ -1
X.if !\\n(1T \{\
X.    BG
X.    if n .sp 4
X.    if t .sp 2
X.\}
X.if !\\n(NX .nr NX 1
X.if !\\n(NX=\\n(NQ \{\
X.    RT
X.    if \\n(NX>1 .bp
X.    mk
X.    nr NC 1
X.    po \\n(POu
X.\}
X.if \\n(NQ>1 .hy 12
X.nr NX \\n(NQ
X.nr CW \\n(L1
X.ll \\n(CWu
X.nr FL \\n(CWu*11u/12u
X.if \\n(NX>1 .nr GW (\\n(LL-(\\n(NX*\\n(CW))/(\\n(NX-1)
X.nr RO \\n(CW+\\n(GW
X.ns
X..
X.de C
X.nr PQ \\n(.f
X.if t .ft 9
X.if "\\$1"" .if n .ul 1000
X.if !"\\$1"" .if n .ul 1
X.if t .if !"\\$1"" \&\\$1\f\\n(PQ\\$2
X.if n .if \\n(.$=1 \&\\$1
X.if n .if \\n(.$>1 \&\\$1\c
X.if n .if \\n(.$>1 \&\\$2
X..
X.ND
X.IZ
X.nr PS 11
X.ps \n(PS
X.nr VS 13
X.vs \n(VSp
X.nr LL 7i
X.ll 7i
X.nr HM -0.1i
X.nr PO -0.3i
X.po \n(POu
X.ds [. \f1[
X.ds .] ]\fP
X.ds Rf References
X.mc
X.hw con-fig-u-ra-tion
X.ds CH
X.ds CF
X.ds Un \\s-1\\fHU\\s-2NI\\s+2B\\s-2ASE\\fR\\s+3
X.ds Da \\s-2\\fHDAMOKLES\\fR\\s+2
X.ds sh \\s-1\\fHshape\\fR\\s+1
X.sp -0.5i
X.ps 16
X.vs 18
X.nf
X.ce 3
XAn Integrated Toolset for Engineering Software Configurations\(dd
X.fi
X.FS
X\(dd in \fIProceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
XSymposium on Practical Software Development Environments\fR
X.br
XBoston MA, 28-30 November 1988
X.br
XACM SIGSOFT SE Notes Vol.13-No.5 / ACM SIGPLAN Notices Vol.24-No.2, pp. 191-200
X.FE
X.vs \n(VSp
X.ps \n(PS
X.sp 0.3i
X\fIAxel Mahler\fR and \fIAndreas Lampen\fR
X.br
XTechnische Universit\*:at Berlin, West-Germany
X.sp 25p
X.Mc
X.LP
X\fBAbstract\fR
X.nr PS 10
X.ps \n(PS
X.nr VS 12
X.vs \n(VSp
X.PP
XConfiguration management in toolkit oriented software development
Xenvironments (SDE), such as the
X.UX
Xsystem, is a long standing nuisance. Mostly, one has to
Xface the choice between poorly or not at all integrated, independent
Xtools, or highly integrated, most specialized, and often language
Xdependent environments. The first choice offers very limited support
Xfor a complex task that needs a broad informational basis. The second
Xchoice often takes away the programmers' most cherished tools, forces
Xhim to adopt some different work discipline, and thereby eventually
Xrestricts his creativity. The toolset described in this paper integrates
Xa dedicated version control system and \*(sh, a significantly enhanced
XMake [Feld79a]
Xprogram, on the basis of a common object model. This object model
Xcomprises multiple versions of software objects as well as conventional
Xfile system objects. Taking this approach made it possible to have
Xa sufficiently integrated toolsystem for engineering software configurations
Xwhile retaining the flexibility of the basic toolbox philosophy, permitting
Xthe use of 'off-the-shelf' tools, e.g. editors or compilers.
X.ps 12
X.nr PS 11
X.ps \n(PS
X.nr VS 13
X.vs \n(VSp
X.NH 1
XIntroduction
X.PP
XConfiguration management is a management technique, designed
Xto control very large development and maintenance projects.
XAs military and government institutions played a principal role
Xin the establishment of configuration management, the related
Xterminology is precisely defined in an ANSI standard [IEEE83a].
XAn in-depth discussion of the underlying concepts can be found in [Bers80a].
X.PP
XTriggered off by the surge of interest in programming environments (PE)
Xduring the last few years, the term \fIsoftware configuration
Xmanagement\fR (SCM) made its way from the management domain
Xtowards
Xthe software engineering and development domain. Today, there are a
Xnumber of PEs with built-in SCM support (e.g. DSEE, Adele,
XISTAR [Lebl84a,\|Estu86a,\|Dows86a]).
XHowever, it is not clear whether SCM is more of a development or
Xmanagement task.  In particular, we suspect that strongly
Xmanagement-oriented approaches to SCM are likely to produce red tape,
Xtending to stand in the (programmer's) way, and consequently
Xdiscourage their systematic application.  On the other hand, strongly
Xde\%vel\%op\%ment-o\%ri\%en\%ted SCM tools often perform a brilliant job in
Xsupporting the programmer, but produce little or no usable information
Xfor project management. To avoid confusion of management-oriented
Xand development-oriented interpretation of SCM, we'd rather prefer
Xthe term \fIsoftware configuration engineering\fR (SCE) to emphasize
Xthe more technical aspects as version control, configuration identification,
Xand system building.
X.PP
XOur toolsystem for engineering of software configurations
Xconsists of
Xan \fIobject base\fR for attributed software objects,
Xa dedicated \fIversion control system\fR, and \*(sh, a significantly
Xenhanced Make program.  Enhancements include full access to the
Xobject base, and support of \fIconfiguration rules\fR which
Xcontrol the selection process for component objects during
Xidentification, build or rebuild of system configurations.
X.PP
XSince integration of version control was a major objective for our
Xsystem, we had to face the need for an object identification scheme
Xthat goes beyond the usual way of specifying just name and type.
XAs a consequence, we began to design an object base for attributed
Xsoftware objects [Lamp88a]
Xthat allows to attach any number of attributes to software objects,
Xand introduces a much more generalized scheme
Xfor object identification.  The object base's name, \fIattributed
Xfilesystem\fR (AFS), mirrors the basic idea, to enhance the regular
X.UX
Xfilesystem by supporting more fileattributes than
Xjust a name and the information stored in the inode.
XThe AFS comprises concepts for
Xversion control, support of variants or status models for example. Furthermore,
Xit helps to abstract from the particular underlying data storage
Xsystem. For the AFS application writer it makes no difference whether it is an
Xordinary filesystem or a dedicated database system like e.g. \*(Da [Ditt86a].
X.NH 2
XRelated Systems
X.PP
XAt first glance, the user-level appearance of the \*(sh toolkit resembles
Xa combination of Make and a version control system such as
XSCCS [Roch75a]
Xor RCS [Tich85a].
XOver the last years some unsatisfying attempts have been made to integrate
XMake with source code control systems [Nick83a,\|AUGM83a].
XThe CMS/MMS tool \*([.DECC84a,\|DECM84a\*(.]
Xunder VAX/VMS
Xcorresponds to \fIAugmented Make\fR and SCCS. CMS and SCCS not only
Xprovide a user command interface, but also give application programs
Xdirect access to the version control facilities through a procedural
Xinterface. However, despite availability of these interfaces,
Xneither Make nor MMS are build on top of them and more complex
Xconfiguration management applications find a hard limit in this lack
Xof integration.
X\*(sh's AFS interface can be seen as an extended and more generalized interface
Xto the version control system. \*(sh and the related version control
Xcommands are entirely build on top of this interface.
X.PP
XBesides these toolbox oriented systems, there are some highly
Xspecialized configuration management tools that are usually part of
Xa software engineering environment.
XBecause they are part of an overall tool concept that also includes
Xprogramming languages, the functionality of these tools is often
Xmore comprehensive in terms of consistency enforcement. Cedar's
XSystem Modeller [Lamp83a]
Xand the Gandalf version control facility [Habe82a]
Xfall into this category.
XAn interesting approach to the determination of system configurations
Xbased on sets of software objects and functions to model the relations
Xbetween them is presented in Jasmine [Marz86a].
X.PP
XCommon to all of the systems mentioned above is that a system description
Xdocument (\fIsystem model\fR) is employed to define components and
Xoverall architecture of a software system.
XIn contrast to that, the Adele configuration manager \fIderives\fR a
Xconfiguration from a system description
Xin terms of \fIdesired characteristics\fR
Xrather than some sort of component list. The description
Xis evaluated against a \fImodule dependency graph\fR and \fImanuals\fR
X(module descriptions) stored in a database of programs.
XThe Odin System [Clem86a]
Xin turn uses a (compiled) knowledge base, called \fIderivation graph\fR,
Xdescribing derivative relationships between \fIdocument types\fR,
Xand associated tools to perform necessary derivations
Xin order to obtain a requested object.
XOdin integrates remarkably well with the standard
X.UX
Xtool environment
Xand can be used to construct comprehensive special purpose environments
Xfrom existing tools [Wait88a].
X.PP
XFinally, DSEE
Xrepresents to the authors' knowledge the most
Xoutstanding configuration management system so far. It is based on system
Xmodels, describing the version-independent structure of a software
Xsystem and \fIconfiguration threads\fR, describing the version
Xrequirements that must be met by the elements of a configuration to be
Xidentified. DSEE combines configuration management with sophisticated
Xproject support facilities, enabling large programmer teams to cooperate
Xover a (local or wide area) computer network.
X.PP
XIn the design of \*(sh, we tried to adopt a number of the best
Xconcepts mentioned above. Namely Make, Adele and DSEE had a strong
Xinfluence on the design of the \*(sh toolkit.  Despite the integration
Xof the toolkit itself, care has been taken to smoothly fit the SCE
Xsystem into the standard
X.UX
Xenvironment. The entry cost for new
Xusers (in terms of initial learning effort) is very low. The system may be
Xused as just a friendly version control tool, an upward compatible
Xreplacement for Make, or an intelligent integration of both.
XUtilization of the toolkit can be gradually extended up to a network
Xbased project support environment, employing a number of programmer
Xteams working on large software development and maintenance projects.
X.PP
XThe simple,
X.UX-like
Xnature of the toolkit's basic user interface
Xoffers a broad range of possibilities to create dedicated user
Xinterfaces that provide an integrated, problem oriented view of the
XSCE system.  Currently in the works are an implementation of a
Xspecially tailored SCE shell on the basis of \*(Th [H\*u87a]
X(a graphical user interface system), and an implementation of a SCE-tool for
Xthe \fIX Window System\fR.
X.PP
XThe rest of this paper describes the \*(sh program and AFS, the
Xobject base on top of which \*(sh and the version control commands
Xare built. Also, a number of problems,
Xencountered while trying to introduce general support for the
Xhandling of \fIvariants\fR, and implementing AFS on top of \*(Da,
Xwill be discussed.
X.NH 1
XThe Shape Toolkit
X.PP
XThe user interface of the SCE toolkit consists of a set of commands for
Xversion control, project interaction, and the shape program itself.
XThe appearance of the version control commands is not unlike to
XRCS' user interface. There are funtions to save and restore
Xan object version (\fCsave/retrv\fR), to manipulate object histories
Xand attributes of object versions (\fCvadm [ -delete | -setattr | -chmod
X\fR(etc.) \fC]\fR), as well as a funtion to obtain information about
Xthe contents of the object base (\fCvl\fR, gives a \fCls(1)\fR-like
Xview of the object base).
X.PP
XThe toolkit supports a basic project organization scheme that
Xdistinguishes private workspaces for individual developers, and a
Xcentral library that is shared by the project team. The project
Xlibrary is administered by the system integrator. The toolkit provides
Xfunctions for project interaction, controlling concurrent development
X(\fIobject locking\fR), and orderly submission of software objects.
X\fCresrv\fR (developer) attempts to reserve the update privilege for a
Xdocument history, \fCsbmit\fR (developer) submits a work result to be
Xincluded into the next release of a system, \fCaccpt\fR (system
Xintegrator) accepts a submitted document version and gives it an
Xofficial, publically accessible state, and \fCrject\fR (system
Xintegrator) denies a submitted work result the official state and
Xsends a corresponding message to the submitting programmer.
X.PP
XVersion control and project interaction are functionally supported
Xby a built-in general version status model. The states \fCbusy\fR,
X\fCsaved\fR, \fCproposed\fR, \fCpublished\fR, \fCaccessed\fR, and
X\fCfrozen\fR are not only intended to say something about the relative
Xquality of a particular object version, but also reflect whether an
Xobject version is in a developer's private experimentation domain, or
Xin the project's official domain, where it is visible and accessible
Xto the entirety of a project team. A more detailed description of the
Xversion control system can be found in [Mahl88a].
X.PP
XThe first implementation of \*(sh resembles Make.  As
Xin Make, the configuration process is controlled by a system
Xdescription document.
XUnlike Make, however, \*(sh operates on objects in an object base
Xrather than
X.UX
Xfilesystem objects.
XWhen building a certain configuration,
X\*(sh searches the object base for appropriate
Xversions of a system's component objects, installs them temporarily
Xas
X.UX
Xfilesystem objects (regular files), eventually invokes some of
X.UX's
Xstandard tools on them, and stores the resulting \fIderived objects\fR
Xin the object base.
XAccordingly, the most significant improvement with respect to Make is
Xthe introduction
Xof \fIselection rules\fR into the
Xdescription document, the \fIShapefile\fR. Selection rules control the
Xselection process for component versions during identification, build or
Xrebuild of system configurations.
X.KS
X.LP
XThe system description document used by \*(sh consists
Xof four basic components:
X.in +0.2i
X.IP \(bu 0.2i
Xsystem description
X.IP \(bu
Xselection rules
X.IP \(bu
Xtransformation rules, and
X.IP \(bu
Xvariant definitions.
X.in -0.2i
X.KE
X.LP
XWhile the syntax for the
Xsystem description part is the same as for Makefiles,
Xthe remaining \*(sh-file sections have a slightly different
Xsyntax from Makefiles and must be preceded and ended by
Xspecial comment sequences (\fC\s-1#%\ RULE-SECTION, #%\ VARIANT-SECTION,
X#%\ END-RULE-SECTION\s+1\fR a.s.o.).
X.NH 2
XSelection of Component Objects
X.PP
XConfiguration selection rules are used to \fIbind concrete object
Xinstances\fR in the object base to \fIcomponent names\fR applied
Xin the Shapefile at build time.  A selection rule is a
Xnamed sequence of \fIalternatives\fR, separated by semicolons,
Xconstituting a logical OR expression. Each alternative consists of a
Xsequence of \fIpredicates\fR, separated by commas, constituting a
Xlogical AND expression.  A selection rule \fIsucceeds\fR if one of its
Xalternatives succeeds (i.e. leads to the unique identification of some
Xobject instance).
X.PP
XA selection rule that \- when activated \- would cause the configuration
Xof an experimental system (\fI\(lqselect the newest version of all components
Xthat I am working on; select the newest published version of all other
Xcomponents\(rq\fR) might look like:
X.LP
X.nf
X\fC\s-1exprule:
X    *.c, attr (author, andy),
X       attr (state, busy);
X    *.c, attrge (state, published),
X       attrmax (version).\s+1\fR
X.fi
X.PP
XAnother example illustrates how known versions of particular modules
Xcould be configured into otherwise experimental systems:
X.LP
X.nf
X\fC\s-1special_rule:
X    afs_def.h, attr (version, 8.22);
X    afs_hparse.c, attr (version, 8.17);
X    *.c, attr (author, andy),
X       attr (state, busy);
X    *.c, attrge (state, published),
X       attrmax (version).\s+1\fR
X.fi
X.PP
XIn alternatives, the first predicate (e.g. \fC*.c\fR) is usually a
Xpattern against which the name attribute of a sought component
Xis matched.  The patterns used by \*(sh have the same structure as those
Xused by \fCed\fR.
XThe other predicates allow certain requirements to be expressed with respect
Xto the object attributes. \fIAttr\fR and \fIattrge\fR are
Xpredefined predicates that require a specified attribute to be equal
Xor greater-than-or-equal (with respect to a defined or lexical
Xorder) a given value. The similarly predefined predicate \fIattrmax\fR
Xrequires objects to have a maximal value in the specified attribute.
XIn order to uniquely identify exactly one object instance by
Xevaluation of a selection rule, the alternatives must be sufficient to
Xsingle out one element from a possible set. Usually, the last predicate
Xof an alternative guarantees a unique selection. Predicates like
X\fIattrmax (attribute_name), attr (state, busy), \fRor\fI attr
X(version, 4.2)\fR are examples of such selections.
X.PP
XThe basic procedure of \*(sh is similar to Make's: Names \- so-called
X\fItargets\fR \- are produced. \*(sh checks whether the
Xtarget already exists and is \fIcurrent\fR, or tries to produce it
Xfrom its \fIdependents\fR.
XA target is considered current if neither the source objects nor the
Xderivation context have changed.
XIn order to check whether a given target
Xis current, both the target document itself, and all of its dependents,
Xmust be configured. A name\(dg
X.FS
X\(dg Conceptually, name \fIand type\fR of a document are passed as implicit
Xparameters. In this discussion, \fIname\fR stands for the concatenation
X\fIname.type\fR
X.FE
Xthat has to be configured is passed as implicit parameter to the
Xactive selection rule. During rule evaluation, the name is
Xsequentially matched against the name pattern of the rule
Xalternatives. If a pattern matches a name, the attempt will be made to
Xcomplete the following predicate sequence.
X.PP
XAfter a name match, \*(sh queries the object base for all objects with
Xthe given name and thereby initializes
Xan internal \fIhit set\fR. The subsequent sequence
Xof predicates will be applied to the set of found AFS objects. An
Xalternative fails if one of the following conditions is true:
X.in +0.2i
X.IP \(bu 0.2i
Xthe pattern does not match
X.IP \(bu
Xa predicate of the alternative fails
X.IP \(bu
Xupon completion of the alternative, the cardinality of the hit set is
Xnot equal to one, i.e. no unique name resolution was possible.
X.in -0.2i
X.LP
XThe application of predicates to the hit set results in the removal of
Xall AFS objects from the hit set that do not conform to the specified
Xrequirements. A predicate's evaluation fails if the cardinality
Xof the hit set becomes equal to zero.
XAfter the target and all of it's dependents have been configured,
Xthe transformation predicate is applied to the target and each of its
Xdependents.
X.PP
XSelection rules can be activated on a per production basis by simply
Xgiving the name of the rule as the first dependent of a production.
XThus, it is possible to define targets for the configuration of e.g.
Xtestsystems and releasable systems within the same \*(sh-file.
X.LP
X.nf
X    \fC\s-1test: exp_rule prog
X    release: rel_rule prog
X    prog: x.o y.o z.o\s+1\fR
X.fi
X.PP
XA selection rule remains active until it is superseded by activation
Xof another selection rule or until the target that caused the activation
Xis produced. If no selection rule is specified, the default rule, which
Xis the same as Make's (\(lq\fIselect the busy object in the current
Xdirectory\fR\(rq), is active.
X.PP
XAfter having uniquely identified the system's components, they will
Xbe temporarily installed as
X.UX
Xfilesystem objects, and the necessary
Xtransformation actions can be performed.
X.PP
XThe search space for retrieve operations is defined by
Xthe \fIcurrent project\fR which is an explicitly selected work context.
XIf \*(sh cannot find a document in the local search space,
Xit tries to connect to a \fIproject server\fR, whose address is
Xdefined by the current project. The project server might reside locally
Xor somewhere in the network. It provides controlled access to the
Xproject's database. Thus, if a particular document could not be tracked
Xdown locally, it might still be somewhere in the project library.
X.NH 2
XTransformation Rules
X.PP
X\*(sh's transformation rules describe, which kind of \fIsource object\fR
Xis transformed into which kind of \fIderived object\fR, how this
Xtransformation is performed, and which parameters are significant
Xfor that transformation.
XTransformation rules consist of a \fItransformation specification\fR,
Xand a \fItransformation script\fR. Transformation specifications
Xdescribe prerequisites and resulting objects of a transformation. The
Xtransformation script is a template for a shell script that
Xwill be passed to a shell process upon activation of a transformation.
XThe syntax for these rules is an extension of Make's default rule
Xspecification formalism. \*(sh's rule by which the transformation
Xof a C source object into a '\fC\&.\&o\fR' (speak: dot-o) derived object
Xis defined looks like:
X.LP
X.nf
X.C
X\s-1%.o: %.c : +(CC) +(CFLAGS)
X    $(CC) -c $(CFLAGS) %.c\s+1
X.R
X.fi
X.LP
XA request to produce a derived object \- let's say \fCxyzzy.o\fR \- would,
Xby evaluating the transformation rule, result in the compilation
Xof \fCxyzzy.c\fR with the compiler defined by
Xthe macro \fCCC\fR, with compile switches defined by \fCCFLAGS\fR.
XThe percent sign is consistently substituted by the name \(lqxyzzy\(rq
Xthroughout the transformation rule. The notation \fI$(NAME)\fR substitutes
Xthe value of the macro \fINAME\fR, while \fI+(NAME)\fR substitutes the
Xentire macro definition (i.e. \fINAME=value\fR).
X.PP
XWhen a transformation rule is evaluated, the name of the source object
Xis passed to the current selection rule and thereby bound to a
Xconcrete source object version in the object base. After the
Xtransformation script has been executed (successfully), \*(sh assumes
Xthat the specified derived object has been produced, and stores the
Xfilesystem object that represents the derived object (in the example
Xabove \fCxyzzy.o\fR) in a special area in the object base, called the
X\fIbinary pool\fR. When put into the binary pool, an attribute
Xdescribing the transformation that just took place, is attached to the
Xderived object. This \fIderivation attribute\fR contains the
Xidentification of all source objects, as well as the definitions of
Xthe specified macros that were used in the transformation script.
X.PP
XIn Make, triggering of transformations is controlled by the built-in
Xpredicate \fIis_newer (target, source)\fR. This predicate fails to
Xproduce a target, if a source object is left unchanged, but something in the
Xproduction environment changed. A common example of this case in
X.UX
Xis the compilation of the same C source file with different precompiler
Xswitches. On the other hand, transformations can be omitted, if the source
Xwas a saved version and the derived object is still existent in the
Xbinary pool. When requested to produce a target, \*(sh configures
Xthe source objects (by evaluating the selection rule), constructs the
Xderivation attribute that \fIwould be\fR assigned to the derived object, and
Xchecks if a derived object
Xthat already has such an attribute is readily available from the binary
Xpool. In this case no compilation would be necessary. If something in
Xthe source context or the transformation context has changed (e.g.
Xthe compile switches in \fCCFLAGS\fR), a new derived object instance
Xwould be created.
X.NH 2
XVariant Support
X.PP
XThere is a common understanding of variants as \fIalternative\fR realizations
Xof the same concept. The typical example
Xfor the genesis of variants is porting of software products to
Xdifferent architectures. The idea of variants sounds quite simple, but
Xto actually handle them can be an extremely difficult task.
X.PP
XVariant documents can be represented by a single source document that has
Xto be \fIpreprocessed\fR in order to access a particular variant.
XVariant documents can also be \fIphysically separated\fR, i.e. each variant
Xis a document of its own. Variants of this kind may have different
Xnames, or the same name but in different name spaces (e.g. directories).
XVariants can be identified by supplying a set of options to the preprocessor
Xor appropriate names or pathnames. Both techniques have their particular
Xadvantages and disadvantages. In the case of preprocessed variants,
Xone has to write source documents that contain lots of precompiler-
Xor macroprocessor-related code. When things grow complex, it is easy
Xto make mistakes. Besides, source documents of this kind are hard to read
Xand understand. Consequently, they are less maintainable.
XAlso, the specification of a planned configuration may require a lot
Xof error-prone work.
X.PP
XThe other case, the physically separate administration of variants, is
Xexpensive in terms of disk space and organizational overhead.
XMoreover, it is extremely problematic when changes (e.g. bug-fixes,
Xfeature enhancements) are made in sections that are common to all
Xvariants. One has to face the choice of
X.in +0.2i
X.IP \(bu 0.2i
Xdoing the work all over again
Xfor all variants,
X.IP \(bu
Xtrying to \fImerge\fR changes that have been made in
Xone variant (semi-) automatically into the others, or
X.IP \(bu
Xchanging only one
Xvariant (the best selling) and abandoning the others.
X.in -0.2i
X.PP
XThe real problem is even more complex. We suspect that it is still an
Xunsolved problem of software engineering to produce \fIportable
Xsoftware designs\fR in the sense of predicting and planning the possibility
Xthat certain modules of a system sprout variant branches.  It is still
Xa fact that variants \fIhappen\fR. In order to port a system to some
Xnew architecture (that might not have even existed at the time of the
Xsystem's design), almost any module might be struck by the necessity
Xof minor or major adjustments. As a consequence, both techniques of
Xvariant administration may happen to be mixed. Also variants of
Xvariants (sub- or multivariants) may come into existence.  A complex
Xsystem often has lots of variant options that are completely
Xindependent (e.g. a compiler that produces French diagnostics and VAX
Xcode for a
X.UX
XSystem V environment). Variant properties of different modules
Xmight also be dependent or contradictory (e.g. certain memory
Xmanagement algorithms may rely on virtual memory, which a specified
Xtarget architecture lacks).  Furthermore, it is easily possible that
Xthe overall structure of a software system becomes variant.  All this
Xcomes to a climax at a point where module variation is a mere
Xsymptom of metamorphosis, in which a system variant evolves into a
Xcompletely different product. The question arises, how long variants
Xshould be treated as such, and when they start a life of their own.
X.PP
XWe don't claim
Xthat \*(sh offers a \(lqquick fix\(rq for the variant problem.  For
Xtools like \*(sh, only flexibility, rather than conceptual or
Xmethodological corsets can be an answer.
X\*(sh offers a simple but flexible mechanism for the
Xhandling of variants that supports both elementary administration
Xconcepts and their combination. For the realization in a
X.UX
Xfilesystem environment, \*(sh allows \fIvariant names\fR to be defined
Xand to be associated with variant-flags, that may be passed to the
Xtransforming tool, and a variant-path, that extends the search space
Xby directories, which could host an object variant. The following
Xexample illustrates the use of variant definitions:
X.LP
X.nf
X\fC\s-1#% VARIANT-SECTION
Xvclass system ::= (vaxbsd, munix)
Xvclass database ::= (damokles, unixfs)
Xvaxbsd:
X    vflags="-DUNIX -DBSD43 -DSTDCC \e
X       -DVAX -DPSDEBUG"
X    vpath="sys/vaxbsd"
Xunixfs:
X    vflags="-DFS"
X    vpath="data/unixfs"
X.sp 2p
X    (\ .\ .\ .\ )
X.sp 2p
X#% END-VARIANT-SECTION\s+1\fR
X.fi
X.PP
XVariant names, as defined in the variant section, can be applied in
Xselection rules through the predefined (pseudo-)predicate \fIattrvar\fR.
XThey provide a unified concept for the administration of variants within
Xthe version control system, with preprocessor technique, and with
Xphysical separation. Configuration selection rules making use of
Xthe variant attribute might look like:
X.LP
X.nf
X\fC\s-1fsexp:
X  *.[ch], attrvar (vaxbsd), \e
X    attrvar (unixfs), attr (state, busy).
X.fi
X.LP
X\*(sh uses the special macros \fIvflags\fR and \fIvpath\fR to hold
Xpreprocessor options and extensions to the default document search
Xpath.
XLocations specified by \fIvpath\fR are searched for
Xdocuments prior to the default location. If a document with the specified
Xattributes is found in a \fIvpath-\fRdirectory, the default directory
Xwill \fInot\fR be searched.
X.PP
XInitially, both macros have an empty value. When variants are selected
Xin an alternative of a selection rule, the associated macro values are
X\fIadded\fR to \fIvflags\fR and \fIvpath\fR. In our example, during
Xevaluation of rule \fCfsexp\fR,
X\fIvflags\fR would become:
X.sp 5p
X.nf
X\fC\s-1vflags="-DUNIX -DBSD43 -DSTDCC \e
X    -DVAX -DPSDEBUG -DFS"\s+1\fR
X.fi
X.sp 5p
Xand \fIvpath\fR  would be:
X.sp 5p
X.nf
X\fC\s-1vpath="sys/vaxbsd:data/unixfs"\s+1\fR.
X.fi
X.sp 5p
XUpon completion of each alternative both macros are reset.
X.PP
XThe construct \fIvclass system ::= (vaxbsd, munix)\fR defines a
X\fIvariant class\fR. Variant classes define mutually exclusive variant
Xnames. Variant classes can usually be given meaningful names, because
Xthey mostly correspond to certain properties, in which the particular
Xvariants vary. A variant class \fIcputype\fR for instance, with
Xelement names \fIIBM4381, VAX630, VAX7XX, m68k\fR a.s.o. might be
Xdefined in order to prevent the selection of different cpu-specific
Xmodules with mismatching cpu attributes. \*(sh will complain if such a
Xcondition is detected.  So far, this is the only concept in \*(sh for ensuring
Xsemantic consistency across variant system components.
XIn this area, more work needs to be done. For a more thorough discussion
Xof this matter, we refer to [Perr87a].
X.NH 2
XConfiguration Identification and Reproducibility
X.PP
X\*(sh can, for the purpose of configuration identification, be asked
Xto produce a \fIconfiguration identification document\fR (CID) for a
Xconfiguration. CIDs have the form of a Shapefile that is \fIcompletely
Xbound\fR. All components of the configuration are precisely identified
Xby their version number, and eventually variant identification. The
XCID also contains all necessary macro definitions.  It is a good idea
Xto place the tools that are used to create system configurations
Xunder version control as well. If this has been done, the tool
Xversions are also included in the CID.  Another important information
Xrecorded in the CID is the \fIproject domain\fR. It defines the name of
Xthe project from which a configuration originates, and the next-higher
Xdomain in which the projectname can be resolved (e.g.  a network\-,
Xhost\-, or pathname). This is necessary in order to define the object
Xbase against which a possible rebuild of the configuration shall be
Xdone.
X.PP
XRecording of system configurations in CIDs is the prerequisite
Xfor proper rebuilds of a complex system. The ability to rebuild
Xa released configuration is in turn the prerequisite for proper
Xproduct maintenance.
XThe fact that \*(sh CIDs are themselves Shapefiles makes it very
Xeasy to reproduce a recorded configuration, provided the original object
Xbase is available and intact.
X.PP
XHowever, complete reproducibility of system releases is a goal that is hard
Xto achieve. To rebuild old configurations as identically as possible
Xnot only requires keeping all document versions that have ever been
Xpart of a release, but also a straight history of all tools (e.g. compilers)
Xthat have ever been used to produce releases. The cost for this might be
Xconsiderable administrative overhead, because every project
Xneeds a current \fItool registry\fR, where all production tools
Xare logged. The gain on the other hand is increased security for the
Xmaintenance phase of long lived software products. The \*(sh toolkit
Xwill offer support for tool registries but not require to keep them.
X.NH 1
XThe Object Base
X.PP
XMost conventional filesystems, such as those of the
X.UX
Xflavor, solely use a file's
X(path-) name to establish access to its
Xcontents.
XThey usually offer no provision for the maintenance of object
Xhistories. Version control systems like SCCS or RCS
Xhad to be introduced as auxiliary tools to avoid the problem of
Xconflicting filenames and to store versions in an efficient manner.
XHistories of related objects are typically maintained completely
Xindependently, so there is no obvious way to figure out which versions
Xof which objects were meant for each other.  Integration of version control
Xwith system
Xbuilding tools like Make is very poor.
XThe choice, which component
Xversions go into a system configuration, is often limited to the
Xselection of either the \fInewest available\fR versions or
X\fIstatically designated\fR, i.e. a priori known versions (composition
Xlist).
X.PP
XFor configuration identification it is more desirable to
X\fIdescribe\fR a planned configuration in terms of
Xproperties that its components must have in order to be eligible.
XThe \fIattributed filesystem\fR (AFS) provides an
Xextended view of software objects to application programs. This view comprises
Xthe concept of \fIobject histories\fR, as well as the possibility to
Xtag any number of \fIuser-defined attributes\fR to object instances.
XInterpretation and use of these
Xattributes is left to the application that uses them.
X.NH 2
XThe Attributed Filesystem
X.PP
XThe term attributed filesystem is only used for historical
Xreasons. The AFS layer described in this section rather implements a
Xdata storage system independent base of \fIattributed software objects\fR\(dg
X.FS
X\(dgWe adhere to the terminology proposed in [Tich88a].
X.FE
X(ASO), on top
Xof which all programs of the configuration engineering toolkit are
Xbuilt.
X.PP
XEach software object
Xis understood as a complex of \fIcontent
Xdata\fR and a set of \fIassociated attributes\fR.
XAttributes
Xhave the general form \fIname=value\fR, where \fIname\fR represents
Xthe attribute name, and \fIvalue\fR a possibly empty attribute value.
XThere are some implicitly defined \fIstandard attributes\fR for
Xevery object instance.  Some of the standard attributes (e.g.
Xname, size, owner, or protection attributes) are inherited from the
Xunderlying data storage system;
Xothers (e.g. revision number or state) are AFS specific.
X.PP
XAFS is realized as a callable interface to a \fIdata storage
Xsystem\fR and provides a general, attribute based method to identify
Xobjects in the object base.  All attributes are considered equally
Xsuited for object identification. For instance, it is possible to
Xretrieve all ASOs with an attribute \fIname=xyzzy\fR, or all
Xitems that have the attributes \fIauthor=andy\fR and
X\fIstate=published\fR.  Versions are treated as \(lqjust another
Xattribute\(rq. AFS provides applications \- such as \*(sh \- with
Xfully transparent, stream oriented access to all object instances.
X.sp 5p
X.KS
X.sp 4c
X.ce
X\f3Fig 3.1.\f1 "The AFS and its applications"
X.KE
X.sp 5p
X.PP
XWith AFS, software objects are retrieved by specifying an \fIattribute
Xpattern\fR.  An AFS retrieval results in a \- possibly empty \- set of
X\fIobject keys\fR, each of which representing a unique object instance
Xthat matches the specified attribute pattern.
X.PP
XThe current implementation of AFS uses two
Xkinds of special files to realize the described concept of ASOs,
X\fIhistory files\fR and \fIbinary pools\fR.  Both file types are
Xarchives and capable of holding a possibly large number of objects.
XHistory files store successive versions of
Xsource objects, which are
Xin most cases of textual nature. To preserve diskspace,
Xonly differences
Xbetween successive versions are kept (\fIdelta technique\fR).
XThe version control system employs
Xa new delta technique [Obst87a],
Xyielding deltas that
Xare about 30 percent smaller than deltas generated by \fIdiff\fR
X(the standard
X.UX
Xcomparison tool for generating deltas).
X.PP
XBinary pools are designed to hold \fIderived\fR objects, i.e. objects
Xthat are produced by processing (transforming, compiling) of source
Xobjects. Since derived objects can be reproduced from a corresponding
Xsource object, binary pools are administered in a cache fashion,
Xi.e. when space runs short, binaries are cleaned out on a \(lqleast
Xaccessed\(rq basis. The concept of binary pools resembles
XDSEE's \fIderived object pools\fR.
X.PP
XSimilar to other version control systems, history files generally
Xaccompany a regular file, the so called workfile. In the context of
X\*(sh and AFS, we use the term \fIbusy object\fR, instead of
Xworkfile.  Busy objects are regular files, thus making it
Xpossible to use tools, such as the EMACS editor, which don't know
Xabout the AFS.  Access to non busy objects however, can only be
Xestablished through the AFS interface, because usually they must
Xfirst be regenerated from the information stored in the corresponding history
Xfile. When a saved version is opened, the I/O operations
Xwill actually access a temporarily created file. All the action
Xhappens \- of course \- behind the scenes, and an AFS application
Xaccesses busy objects as well as all other versions transparently
Xthrough the same mechanism.
X.PP
XThe attributes of all version instances of an object, including the
Xbusy object, are stored in the history file. Attributes of derived
Xobjects are stored in the binary pool file that hosts them.
X.PP
XEvery regular file can be accessed through the AFS.  In this case, it
Xwill be treated as a busy object without AFS specific or user-defined
Xattributes.  If such a file is checked into the version control system
Xfor instance, a history file will be created, and the missing standard
Xattributes will be supplemented in a meaningful manner.
X.NH 2
XAFS on top of \*(Da
X.PP
XA second implementation of AFS on top of \*(Da, a dedicated software
Xengineering database (prototype) is currently under way.
X\*(Da is based on an \fIextended entity relationship model\fR and designed
Xto serve as universal data management system for a large set of tools
Xto be part of an integrated programming environment.
X.PP
XThe fact that the various tools are supposed to store their data in a
Xtool specific structure (of entities and relationships) leads to
Xsome serious problems. First, opening of an ASO containing application
Xspecific \*(Da structures must yield an object specific key rather
Xthan a
X.UX
Xfile pointer. Second, simple operations such as copying,
Xmoving, or printing of object contents are representation dependent and
Xcan't be performed by the AFS any more. In particular, there is no easy
Xway for AFS to compute \fIversion deltas\fR between \*(Da object structures
X(how should this kind of delta look like ?).
X.PP
XAnother very practical problem is extensibility. In the current state,
Xa \*(Da database has \fIone\fR schema that defines the internal
Xstructure of the entire database.  Addition of a new tool with the
Xnecessity of schema updates requires the generation of a new database
Xand the (troublesome) transfer of all data from the old database to
Xthe new one.  Due to these problems and the current lack of of \*(Da
Xbased tools, we decided to use the database only as replacement
Xfor archive\- and binary pool files.
XBusy objects and temporary files (containing the data of
Xreconstructed older versions) are still stored in the
X.UX
Xfilesystem.
XAFS applications have no direct access to the database.  Similar to
Xthe filesystem implementation, the contents of an ASO has the form of
Xa byte array.  Until now, there is no substantial difference between this
Ximplementation and the filesystem implementation \(em except that it
Xwill be slower.
X.PP
XA solution to the described problems that will allow AFS applications
Xto take full advantage of \*(Da' structuring facilities while
Xsupporting the dynamic extension of the SPU without the necessity to
Xchange or even recompile any part of the environment, can be found by
Xtaking a consequently object oriented approach.  The design of an
Xobject oriented AFS to be basic part of an object oriented \fIenvironment
Xframe\fR is currently in its early stage. However, we expect substantial
Xresults in this direction in the near future.
X.NH 1
XConclusion
X.PP
XThe described system for engineering of software configurations
Xintegrates tools for version control, system building, and
Xproject organization on top of a common object concept. Despite the
Xintegration of the toolkit itself, care has been taken to smoothly fit
Xthe SCE system into the standard
X.UX
Xenvironment. The entry cost for
Xnew users (in terms of initial learning effort) is very low. The
Xsystem may be used as just a friendly version control tool, an upward
Xcompatible replacement for Make, or an intelligent integration of
Xboth.  Utilization of the toolkit can be gradually extended up to a
Xnetwork based project support environment, employing a number of
Xprogrammer teams working on large software development and maintenance
Xprojects.
X.PP
XThe simple,
X.UX-like
Xnature of the toolkit's basic user interface
Xoffers a broad range of possibilities to create dedicated user interfaces
Xthat provide an integrated, problem oriented view of the SCE system.
X.PP
XThere are, however, a number of areas where much more work needs to
Xbe done. Particularly, powerful formalisms to deal with the complexity
Xof variant control are still at large. The use of software engineering
Xdatbases as underlying data storage system is still a problem. However,
Xthe use of object oriented design principles for a new version of the
Xsystem is expected to overcome these problems and to open up exciting
Xperspectives for a \(lqgeneric, integrated, open software engineering
Xtoolkit environment\(rq.
X.NH 1
XAcknowledgement
X.PP
XThis work is part of the \*(Un project. The project is supported by the
XBundesministerium f\*:ur Forschung und Technologie
X(Federal Ministry for Research and Technology) under grant ITS 8308.
X.]<
X.\"AUGMAKE-1983-1
X.ds [F AUGM83a
X.]-
X.ds [A AUGMAKE
X.ds [T An Augmented Version of Make
X.ds [J System V/68 Support Tools Guide
X.ds [I Motorola Microsystems Inc., Ord.No. M68KUNSTG/D1
X.ds [P 21-40
X.nr [P 1
X.ds [D January 1983
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Bersoff.E.H.-1980-2
X.ds [F Bers80a
X.]-
X.ds [A Edward H. Bersoff
X.as [A ", Vilas D. Henderson
X.as [A ", and Stanley G. Siegel
X.ds [T Software Configuration Management
X.ds [I Prentice Hall
X.ds [C Englewood Cliffs, N.J.
X.ds [D 1980
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 2 book
X.\"Clemm.G.M.-1986-3
X.ds [F Clem86a
X.]-
X.ds [A Geoffrey M. Clemm
X.ds [T The Odin System: An Object Manager for Extensible Software Environments
X.ds [J CU-CS-314-86
X.ds [I The University of Colorado
X.ds [C Boulder, Colorado
X.ds [D February 1986
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"DECCMS-1984-4
X.ds [F DECC84a
X.]-
X.ds [A DECCMS
X.ds [T VAX DEC/CMS 2.0 Reference Manual
X.ds [J VAX DEC/CMS Reference Manual, Order No. AA-L372B-TE
X.ds [I Digital Equipment Corporation
X.ds [C Maynard, Massachusetts
X.ds [D November 1984
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"DECMMS-1984-5
X.ds [F DECM84a
X.]-
X.ds [A DECMMS
X.ds [T VAX DEC/MMS 2.0 User's Guide
X.ds [J VAX DEC/MMS User's Guide, Order No. AA-P119B-TE
X.ds [I Digital Equipment Corporation
X.ds [C Maynard, Massachusetts
X.ds [D August 1984
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Dittrich.K-1986-6
X.ds [F Ditt86a
X.]-
X.ds [A Klaus Dittrich
X.as [A ", Willi Gotthard
X.as [A ", and Peter C. Lockemann
X.ds [T DAMOKLES. A Database System for Software Engineering Environments
X.ds [J International Workshop on Advanced Programming Environments
X.ds [P 351-371
X.nr [P 1
X.ds [I IFIP WG2.4
X.ds [I Springer Verlag
X.ds [C Trondheim, Norway
X.ds [D June 1986
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Dowson.M-1986-7
X.ds [F Dows86a
X.]-
X.ds [A Mark Dowson
X.ds [T ISTAR - An Integrated Project Support Environment
X.ds [J Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
X.ds [J Symposium on Practical Software Development Environments
X.ds [J SIGPLAN Notices
X.ds [V 22, 1
X.ds [P 16-27
X.nr [P 1
X.ds [I ACM
X.ds [C Palo Alto, California
X.ds [D December 1986
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Estublier.J.-1986-8
X.ds [F Estu86a
X.]-
X.ds [A J. Estublier
X.as [A " and N. Belkhatir
X.ds [T Experience with a Database of Programs
X.ds [J Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
X.ds [J Symposium on Practical Software Development Environments
X.ds [J SIGPLAN Notices
X.ds [V 22, 1
X.ds [P 84-91
X.nr [P 1
X.ds [I ACM
X.ds [C Palo Alto, California
X.ds [D December 1986
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Feldman.S.I.-1979-9
X.ds [F Feld79a
X.]-
X.ds [A Stuart I. Feldman
X.ds [T MAKE - A Program for Maintaining Computer Programs
X.ds [J Software - Practice and Experience
X.ds [V 9,3
X.ds [P 255-265
X.nr [P 1
X.ds [D March 1979
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Haberman.A.N-1982-10
X.ds [F Habe82a
X.]-
X.ds [A A. Nico Haberman
X.as [A " and Gail E. Kaiser
X.ds [T An Environment for System Version Control
X.ds [J Dig. Papers Spring Compcon
X.ds [I IEEE
X.ds [D November 1982
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"H\*ubner.W.-1987-11
X.ds [F H\*u87a
X.]-
X.ds [A W. H\*ubner
X.as [A ", G. Lux-M\*ulders
X.as [A ", and M. Muth
X.ds [T THESEUS \- Die Benutzungsoberfl\*ache der UNIBASE Softwareentwicklungsumgebung
X.ds [J Beitr\*age zur Graphischen Datenverarbeitung
X.ds [I Zentrum f\*ur Graphische Datenverarbeitung
X.ds [I Springer Verlag
X.ds [C Berlin
X.ds [D 1987
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"IEEE-1983-12
X.ds [F IEEE83a
X.]-
X.ds [A IEEE
X.ds [T IEEE Standard Glossary for Software Engineering Terminology
X.ds [I IEEE
X.ds [C New York, N.Y.
X.ds [D February 1983
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 2 book
X.\"Lampen.A-1988-13
X.ds [F Lamp88a
X.]-
X.ds [A Andreas Lampen
X.as [A " and Axel Mahler
X.ds [T An Object Base for Attributed Software Objects
X.ds [J (to appear in) Proceedings of the Fall 1988 EUUG Conference
X.ds [I European Unix systems User Group
X.ds [C Lisbon, Portugal
X.ds [D October 1988
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Lampson.B.-1983-14
X.ds [F Lamp83a
X.]-
X.ds [A B. Lampson
X.as [A " and E. Schmidt
X.ds [T Organizing Software in a Distributed Environment
X.ds [J Proc. of the SIGPLAN 83 Symposium on Programming Language Issues in Software Systems
X.ds [V 18, 6
X.ds [P 1-13
X.nr [P 1
X.ds [C San Francisco, California
X.ds [D June 1983
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Leblang.D.B.-1984-15
X.ds [F Lebl84a
X.]-
X.ds [A David B. Leblang
X.as [A " and Robert P. Chase
X.ds [T Computer-Aided Software Engineering in a Distributed Workstation Environment
X.ds [J Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
X.ds [J Symposium on Practical Software Development Environments
X.ds [J SIGPLAN Notices
X.ds [V 19, 5
X.ds [P 104-113
X.nr [P 1
X.ds [I ACM
X.ds [C Pittsburgh, PA.
X.ds [D April 1984
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Mahler.A-1988-16
X.ds [F Mahl88a
X.]-
X.ds [A Axel Mahler
X.as [A " and Andreas Lampen
X.ds [T shape \- A Software Configuration Management Tool
X.ds [J Proceedings of the International Workshop on Software Version and Configuration Control
X.ds [I German Chapter of the ACM
X.ds [I B.G. Teubner
X.ds [P 228-243
X.nr [P 1
X.ds [C Grassau, West-Germany
X.ds [D January 1988
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Marzullo.K-1986-17
X.ds [F Marz86a
X.]-
X.ds [A Keith Marzullo
X.as [A " and Douglas Wiebe
X.ds [T Jasmine: A Software System Modelling Facility
X.ds [J Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
X.ds [J Symposium on Practical Software Development Environments
X.ds [J SIGPLAN Notices
X.ds [V 22, 1
X.ds [P 121-130
X.nr [P 1
X.ds [I ACM
X.ds [C Palo Alto, California
X.ds [D December 1986
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Nicklin.P.J.-1983-18
X.ds [F Nick83a
X.]-
X.ds [A Peter J. Nicklin
X.ds [T The SPMS Software Project Management System
X.ds [I UC Berkeley
X.ds [C Berkeley, CA.
X.ds [D August 1983
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 2 book
X.\"Obst.W-1987-19
X.ds [F Obst87a
X.]-
X.ds [A Wolfgang Obst
X.ds [T Delta Technique and String-to-String Correction
X.ds [J Proceedings of the 1st European Software Engineering Conference
X.ds [J Lecture Notes in Computer Science
X.ds [P 69-73
X.nr [P 1
X.ds [I Springer Verlag
X.ds [C Berlin
X.ds [D September 1987
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Perry.D.E.-1987-20
X.ds [F Perr87a
X.]-
X.ds [A Dewayne E. Perry
X.ds [T Version Control in the Inscape Environment
X.ds [J Proceedings of the 9th International Conference on Software Engineering
X.ds [I IEEE
X.ds [P 142-149
X.nr [P 1
X.ds [C Monterey, California
X.ds [D March 1987
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Rochkind.M.J.-1975-21
X.ds [F Roch75a
X.]-
X.ds [A Marc J. Rochkind
X.ds [T The Source Code Control System
X.ds [J IEEE Transactions on Software Engineering
X.ds [V SE-1
X.ds [P 364-370
X.nr [P 1
X.ds [D 1975
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Tichy.W.F.-1985-22
X.ds [F Tich85a
X.]-
X.ds [A Walter F. Tichy
X.ds [T RCS - A System for Version Control
X.ds [J Software - Practice and Experience
X.ds [V 15,7
X.ds [P 637-654
X.nr [P 1
X.ds [D July 1985
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Tichy.W.F.-1988-23
X.ds [F Tich88a
X.]-
X.ds [A Walter F. Tichy
X.ds [T Tools for Software Configuration Management
X.ds [J Proceedings of the International Workshop on Software Version and Configuration Control
X.ds [P 1-20
X.nr [P 1
X.ds [I B.G. Teubner
X.ds [I German Chapter of the ACM
X.ds [C Grassau, FRG
X.ds [D January 1988
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.\"Waite.W.M.-1988-24
X.ds [F Wait88a
X.]-
X.ds [A William M. Waite
X.as [A ", V. P. Heuring
X.as [A ", and Uwe Kastens
X.ds [T Configuration Control in Compiler Construction
X.ds [J Proceedings of the International Workshop on Software Version and Configuration Control
X.ds [I German Chapter of the ACM
X.ds [I B.G. Teubner
X.ds [P 228-243
X.nr [P 1
X.ds [C Grassau, West-Germany
X.ds [D January 1988
X.nr [T 0
X.nr [A 0
X.nr [O 0
X.][ 1 journal-article
X.]>
END_OF_FILE
if test 49291 -ne `wc -c <'papers/boston.ms'`; then
    echo shar: \"'papers/boston.ms'\" unpacked with wrong size!
fi
# end of 'papers/boston.ms'
fi
echo shar: End of archive 31 \(of 33\).
cp /dev/null ark31isdone
MISSING=""
for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ; do
    if test ! -f ark${I}isdone ; then
    MISSING="${MISSING} ${I}"
    fi
done
if test "${MISSING}" = "" ; then
    echo You have unpacked all 33 archives.
    rm -f ark[1-9]isdone ark[1-9][0-9]isdone
else
    echo You still need to unpack the following archives:
    echo "        " ${MISSING}
fi
##  End of shell archive.
exit 0