home *** CD-ROM | disk | FTP | other *** search
- Subject: v19i043: A software configuration management system, Part30/33
- Newsgroups: comp.sources.unix
- Sender: sources
- Approved: rsalz@uunet.UU.NET
-
- Submitted-by: Axel Mahler <unido!coma!axel>
- Posting-number: Volume 19, Issue 43
- Archive-name: shape/part30
-
-
-
- #! /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 30 (of 33)."
- # Contents: papers/lisbon.ms
- # Wrapped by rsalz@papaya.bbn.com on Thu Jun 1 19:27:19 1989
- PATH=/bin:/usr/bin:/usr/ucb ; export PATH
- if test -f 'papers/lisbon.ms' -a "${1}" != "-c" ; then
- echo shar: Will not clobber existing file \"'papers/lisbon.ms'\"
- else
- echo shar: Extracting \"'papers/lisbon.ms'\" \(46807 characters\)
- sed "s/^X//" >'papers/lisbon.ms' <<'END_OF_FILE'
- X.IZ
- X.sp -0.9di
- X.ND
- X.nr UX 1
- X\" --- cut here ---
- X.AM
- X.ds Rf References
- X.ds Un \\s-1\\f(HBU\\s-2NI\\s+2B\\s-2ASE\\fR\\s+3
- X.ds Co \\s-2\\f(HBCOMA\\fR\\s+2
- X.ds Da \\s-2\\f(HBDAMOKLES\\fR\\s+2
- X.ds Th \\s-2\\f(HBTHESEUS\\fR\\s+2
- X.ds Mk Make
- X.ds sh \\s-1\\f(HBshape\\fR\\s+1
- X.ds Af AFS
- X.TL
- XAn Object Base for Attributed Software Objects\(dg
- X.FS
- X\(dg in \fIProceedings of the EUUG Autumn '88 Conference\fR
- X.br
- X(Cascais, 3-7 October 1988), pp. 95-105, European UNIX Users Group, London 1988
- X.FE
- X.AU
- XAndreas Lampen, Axel Mahler
- Xandy@coma.uucp, axel@coma.uucp
- X.AI
- XTechnische Universit\*:at Berlin
- XSekretariat FR 5-6
- XFranklinstr. 28/29
- XD-1000 Berlin 10
- X.AB
- XThe
- X.UX
- Xfilesystem supports a fixed set of attributes for filesystem
- Xobjects, stored in inodes and directory entries.
- XThe (path-)name attribute is the sole means to identify
- Xand access a filesystem object.
- XThis turns out to be a rather severe limitation for certain
- Xcomplex applications such as large scale software development,
- Xwhere software objects typically evolve in a considerable number of
- Xversions.
- X.LP
- XAn approach to improve the situation
- Xis introduced by the \fIattribute filesystem\fR (\*(Af),
- Xthe system described in this paper.
- XThe \*(Af combines the notion of immutable objects (versions)
- Xwith the possibility to attach any number of user-definable
- Xattributes to any attributed software object (ASO).
- X\*(Af objects can be identified by specifying any set of
- Xattribute value(s) as retrieve pattern.
- XThe \fIname\fR of an \*(Af object is treated as \fIjust another attribute\fR.
- XThe \*(Af is equipped with a proper retrieve interface that allows
- Xnon-unique identification of \fIsets of objects\fR and provides
- Xoperations on those sets.
- X.LP
- XThe \*(Af is a significant extension to the
- X.UX
- Xfilesystem interface providing applications with a unified,
- Xconsistent view of attributed filesystem objects comprising
- Ximmutable versions and ordinary
- X.UX
- Xfiles.
- XThe concept of \fIpersistent objects\fR makes \*(Af a basis
- Xfor object oriented applications in an
- X.UX
- Xenvironment.
- XWe used \*(Af as a basis for the implementation of the \*(sh toolkit,
- Xa collection of programs supporting
- Xsoftware configuration management in multi-programmer software
- Xdevelopment projects.
- X.LP
- XOne important objective of \*(Af is to abstract from the actually
- Xunderlying data storage system. This paper will briefly discuss
- Xtwo different implementations of \*(Af \- one on top of the
- X.UX
- Xfilesystem and the other based on \*(Da, a dedicated software
- Xengineering database.
- X.AE
- X.NH 1
- XIntroduction
- X.LP
- XThe context of this work was the design of a software configuration
- Xmanagement system to be part of a kernel of an open
- X.UX
- Xbased software engineering environment.
- XLarge scale software development requires a system
- Xcapable to store a big number of software objects, typically
- Xevolving in a considerable number of versions.
- X.LP
- XThe
- X.UX
- Xfilesystem is a good basis for this job but it has
- Xsome severe limitations.
- XIt supports only a fixed set of attributes for filesystem
- Xobjects, stored in inodes and directory entries.
- XThe (path-)name attribute is the sole means to identify
- Xand access a filesystem object.
- XVersion control systems had to be introduced as auxiliary tools,
- Xto avoid name clashes and to store multiple versions
- Xof files in an space efficient manner.
- XHowever, they do not overcome the fundamental shortcomings
- Xof the
- X.UX
- Xfilesystem.
- XThey represent partial solutions to particular problems
- Xand integrate poorly with
- X.UX
- Xtools such as \*(Mk [2].
- X.LP
- XAs a try to overcome these limitations we designed the \fIattribute
- Xfilesystem\fR (\*(Af), the system described in this paper.
- XWe use the name attribute \fIfilesystem\fR mainly for historical
- Xreasons (because we are used to it and we haven't found a better
- Xname yet).
- XSo don't be confused when we subsequently refer to
- X\*(Af as an \fIobject base\fR rather than a filesystem.
- XAccordingly we will use the term \fIsoftware object\fR instead of
- X\fIfile\fR throughout this paper.
- X.LP
- XAn object base is a hybrid of filesystem and database trying
- Xto combine the advantages of both types of data storage systems.
- XThe advantages of an object base over a filesystem
- Xlie in its
- X.IP \(bu 0.2i
- Xmore general object identification scheme,
- X.IP \(bu
- Xability to store multiple versions of objects,
- X.IP \(bu
- Xsupport for the management of arbitrary attributes for objects and
- X.IP \(bu
- Xabstraction from the physical representation of objects.
- X.RE
- X.LP
- XImprovements in respect to database systems are
- X.IP \(bu 0.2i
- Xthe concept \fIobject\fR
- Xas manageable, user identifyable, interchangeable piece of data
- Xand a common understanding of how data looks like (a basis for integration
- Xof existing and new tools),
- X.IP \(bu
- Xno need for a schema (i.e. no problems with schema updates),
- X.IP \(bu
- Xbetter network support (\fIobjects\fR are quite easyly interchangeable
- Xbetween different machines) and
- X.IP \(bu
- Xbetter performance (in most cases)
- X.RE
- X.LP
- XFor a detailed discussion on how a persistent object base should
- Xlook like, see [6].
- X.LP
- X\*(Af is designed as basis for the \*(sh-toolkit, described in [4]
- Xand [5].
- XThe \*(sh-toolkit is a configuration management toolkit
- Xintegrating a dedicated version control system and \*(sh, a
- Xsignificantly enhanced \*(Mk program.
- XEnhancements include full access to the version control system.
- X\*(sh's procedure of identifying
- Xappropriate component versions that together form a meaningful system
- Xconfiguration may be completely controlled by user-supplied \fIconfiguration
- Xselection rules\fR. Selection rules are placed in the \fIShapefile\fR,
- X\*(sh's counterpart to the Makefile.
- X.LP
- XThe next chapter gives an overview of the basic concepts of \*(Af.
- XIn chapter 3, we briefly describe the interface and have a
- Xlook at two different implementations.
- XThe last chapter contains an outlook on current development
- Xefforts to make \*(Af a basis for object oriented applications.
- X.NH 1
- XGeneral design
- X.LP
- X\*(Af is a system to store software objects as
- Xa complex of (from the AFS' point of view) unstructured
- Xcontent data and an arbitrary
- Xnumber of associated attributes.
- XWe call these objects \fIattributed software objects\fR (ASOs).
- X\*(Af has a built-in version control system that supports the storage
- Xand identification of different versions of \fIdesign objects\fR.
- XA design object consists of a group of
- Xsuccessive versions evolving by taking snapshots of the current
- Xdevelopment state from time to time.
- XThroughout this paper we also use the term \fIline of development\fR
- Xsynonymously to \fIdesign object\fR.
- XEach version of a design object is an attributed software object on its own.
- XFor a more detailed discussion of software engineering terms see [10].
- X.LP
- XDue to the requirements of a multi programmer software
- Xdevelopment environment we introduced
- Xa mechanism for reserving update rights for design objects
- Xby setting a lock on this object.
- XReserving the update right has
- Xthe effect, that updates can only be stored by the user
- Xcurrently holding the lock.
- X.LP
- X\*(Af was designed to be a basis for integration of a large spectrum
- Xof different software development tools.
- XThese may be editors, compilers, formatters,
- Xa software configuration management system, tools for
- Xproject planning and status accounting, test support, specification
- Xand design tools \(em a potentially very long list.
- XIn respect to tool integration, an
- Xengineering environment has to offer some form of
- Xintelligent support for the user in order to improve
- Xthe situation presented by mere toolbox systems.
- XHowever, it is not feasible for the object
- Xmanagement part of such an environment to understand the
- Xformal semantics contained \fIin\fR the various types of
- Xobjects it manages.
- XThe functional behavior of an environment's object manager
- Xshould rather be guided by simple information \fIabout\fR the
- Xmanaged objects.
- XAttributes enable each \*(Af application program to store information
- Xabout a software object persistently either for later use or
- Xleaving them for interpretation by other \*(Af applications (or both).
- X.LP
- XIt is likely that the number of needed attributes will grow with each new
- Xtool using \*(Af.
- XAs we cannot foresee which new \*(Af applications will be
- Xintroduced in the future, we are not able to define a fixed set of
- Xattributes serving all needs.
- XInstead, we decided to keep the number of attributes
- Xfor each stored object dynamically extensible.
- XBesides some standard attributes (such as name, size or version),
- Xeach software object is stored with a potentially infinite number of
- Xapplication-defined attributes.
- X.LP
- XAnother important design goal was the introduction of a
- Xconcept for the integration of standard
- X.UX
- Xtools and off\-the\-shelf tools that operate on regular files.
- XFor this purpose, \*(Af is designed to be able to coexist with the
- X.UX
- Xfilesystem.
- XIt allows regular
- X.UX
- Xfiles to be treated as \*(Af objects and to be accessed through the \*(Af
- Xinterface.
- XThis opens a way to exchange data between existing tools that operate on
- X.UX
- Xfiles and tools on top of \*(Af (such as the \*(sh toolkit).
- XFigure 2.1 illustrates the tool integration on base
- Xof \*(Af. \*(Af is a C\-language interface that abstracts from the
- Xunderlying data storage system (e.g. a filesystem or a database).
- X.KF
- X.sp 5p
- X.PS
- X boxht=0.6i
- X move right 0.9i
- XDs: box wid 2.2i "Data Storage System" "(e.g. Filesystem or Database)"
- X box wid 1.9i "UNIX filesystem"
- X move to Ds.nw; move up 0.3i; move right 0.2i;
- XAf: box wid 2.6i "Attribute File System"; move up 0.3i; right
- X box ht 1.2i wid 1i "other" "programs:" "Editors" "Compilers" "Formatters"
- X move to Af.nw; move up 0.3i; move right 0.2i
- X box wid 0.8i "Version" "Control" "Commands"
- X box wid 0.8i "\*(sh"
- X box wid 0.8i "other" "AFS" "Applications"
- X.PE
- X.sp 5p
- X.ce
- X\fBFig. 2.1:\fR The AFS and its applications
- X.sp 5p
- X.KE
- X.LP
- XApart from versions and attributes, \*(Af looks very much like the
- X.UX
- Xfilesystem with a hierarchical directory structure, special files and so on.
- X.LP
- X.NH 2
- XSource objects and derived objects
- X.LP
- X\*(Af manages \fIlines of development\fR. A line of development
- Xconsists of a \fIbusy object\fR and a number of saved versions.
- XThe busy object is an ordinary alterable
- X.UX
- Xfile.
- XIt can be accessed via \*(Af \fIand\fR
- X.UX
- Xfilesytem operations.
- XVersions come into being by making a copy of the current state of
- Xthe busy object.
- XThey can be stored as source objects or as derived objects.
- X.LP
- XSource objects are typically composed manually (e.g. by use of a
- Xtext editor).
- X\*(Af stores source objects as immutable objects.
- XOnce saved, they cannot be modified any longer.
- XThey can only be explicitly removed by their owner or author.
- XSource objects can be uniquely identified by the attribute values
- Xfor \fIhostname, system path, name, type, generation number,
- Xrevision number\fR and \fIvariant\fR.
- X.LP
- XDerived objects are typically derived automatically (e.g. by a
- Xcompiler) from a source object and thus be reproducible at any time.
- XThey are kept in a \fIderived object pool\fR ( see also [3]
- X), a data store of limited
- Xsize that is administered in a cache fashion. The oldest (access
- Xdate) derived objects get removed if space runs short in the binary
- Xpool. Unlike source objects, the tupel (\fIhostname, system path, name,
- Xtype, generation number, revision number, variant\fR) does not necessarily
- Xhave to be unique for derived objects. Derived
- Xobjects may differ only in user defined attributes !
- X.LP
- X\*(Af makes no assumptions whether a copy of a busy object shall be
- Xstored as source object or as derived object.
- XThis has to be decided by the application.
- X.NH 2
- XAttributed Software Objects
- X.LP
- XAttributes have the general form \fIname=[value [value ...]]\fR.
- XFigure 2.2 illustrates the term attributed software object.
- X.KF
- X.PS
- X move right 1.1i
- XDa: box ht 2i wid 1.5i "\s+9\f(HBDATA\fR\s-9"
- X line from Da.nw - 0,0.1 to Da.nw + 0.1,0
- X line from Da.nw - 0,0.2 to Da.nw + 0.2,0
- X line from Da.nw - 0,0.3 to Da.nw + 0.3,0
- X line from Da.nw - 0,0.4 to Da.nw + 0.4,0
- X line from Da.nw - 0,0.5 to Da.nw + 0.5,0
- X line from Da.nw - 0,0.6 to Da.nw + 0.6,0
- X line from Da.nw - 0,0.7 to Da.nw + 0.7,0
- X line from Da.nw - 0,0.8 to Da.nw + 0.8,0
- X line from Da.nw - 0,0.9 to Da.nw + 0.9,0
- X line from Da.nw - 0,1.0 to Da.nw + 1.0,0
- X line from Da.nw - 0,1.1 to Da.nw + 1.1,0
- X line from Da.nw - 0,1.2 to Da.nw + 1.2,0
- X line from Da.nw - 0,1.3 to Da.nw + 1.3,0
- X line from Da.nw - 0,1.4 to Da.nw + 1.4,0
- X line from Da.nw - 0,1.5 to Da.nw + 1.5,0
- X line from Da.nw - 0,1.6 to Da.ne - 0,0.1
- X line from Da.nw - 0,1.7 to Da.ne - 0,0.2
- X line from Da.nw - 0,1.8 to Da.ne - 0,0.3
- X line from Da.nw - 0,1.9 to Da.ne - 0,0.4
- X line from Da.nw - 0,2.0 to Da.ne - 0,0.5
- X line from Da.sw + 0.1,0 to Da.ne - 0,0.6
- X line from Da.sw + 0.2,0 to Da.ne - 0,0.7
- X line from Da.sw + 0.3,0 to Da.ne - 0,0.8
- X line from Da.sw + 0.4,0 to Da.ne - 0,0.9
- X line from Da.sw + 0.5,0 to Da.ne - 0,1.0
- X line from Da.sw + 0.6,0 to Da.ne - 0,1.1
- X line from Da.sw + 0.7,0 to Da.ne - 0,1.2
- X line from Da.sw + 0.8,0 to Da.ne - 0,1.3
- X line from Da.sw + 0.9,0 to Da.ne - 0,1.4
- X line from Da.sw + 1.0,0 to Da.ne - 0,1.5
- X line from Da.sw + 1.1,0 to Da.ne - 0,1.6
- X line from Da.sw + 1.2,0 to Da.ne - 0,1.7
- X line from Da.sw + 1.3,0 to Da.ne - 0,1.8
- X line from Da.sw + 1.4,0 to Da.ne - 0,1.9
- X move to Da.se + 0.5,0
- XAt: line up 2.1i; line right 1.5i; line down 2i
- X move left 1.45i; line right 1.5i; down
- X arc from Here - 0,0.2i to Here rad 0.1i; move down 0.2i
- X line left 1.5i; up; ellipsewid = 0.1i; ellipseht = 0.2i; ellipse
- X move to Da.ne + 0.6i,0; move down 0.1i
- X "name=otto" ljust; move down 0.12i
- X "type=c" ljust; move down 0.12i
- X "generation=4" ljust; move down 0.12i
- X "revision=3" ljust; move down 0.12i
- X "variant=" ljust; move down 0.12i
- X "state=saved" ljust; move down 0.12i
- X "author=andy" ljust; move down 0.12i
- X "mode=0644" ljust; move down 0.12i
- X "mdate=881001-12:22:34" ljust; move down 0.12i
- X "sdate=881002-22:44:16" ljust; move down 0.12i
- X "project=shape" ljust; move down 0.12i
- X "testlevel=low" ljust; move down 0.12i
- X "do_next=fix retrv-bug" ljust; move down 0.12i
- X "..." ljust
- X
- X line from Da.ne - 0,0.9 right 0.5i up 0.1i
- X line from Da.ne - 0,1.1 right 0.5i up 0.1i
- X.PE
- X.sp 5p
- X.ce
- X\fBFig. 2.2:\fR An Attributed software object
- X.sp 5p
- X.KE
- X.LP
- X\*(Af supports a set of standard attributes for each ASO.
- XThese are
- X.IP \(bu 0.2i
- Xhostname, system path, name, type,
- X.IP \(bu
- Xgeneration number, revision number, variant name, version state,
- X.IP \(bu
- Xowner, author,
- X.IP \(bu
- Xsize,
- X.IP \(bu
- Xaccess permissions, lock,
- X.IP \(bu
- Xdate of last modification, \- last access, \- last status change,
- X\- saving and \- last lock change
- X.RE
- X.LP
- XThe \fIsystem path\fR attribute is used to describe the (logical)
- Xposition of an ASO in a complex, hierarchically structured
- Xsystem. \fISystem path, name\fR and
- X\fItype\fR are currently mapped to
- X.UX
- Xpathnames where they take the place of path prefix, filename (without suffix)
- Xand filename suffix. For example: the system path \fC/usr/axel\fR,
- Xname \fCfoo\fR and type \fCc\fR are mapped to the
- X.UX
- Xfilename \fC/usr/axel/foo.c\fR.
- XAdditionally to the \fIowner\fR attribute known from
- X.UX
- Xfiles ASOs also have an \fIauthor\fR attribute.
- X\*(Af distinguishes the \fIowner\fR of an entire design object
- Xand the \fIauthor\fR of a particular version.
- X.LP
- XIn addition to the standard attributes, an application may attach any
- Xnumber of \fIuser defined attributes\fR to any ASO.
- XInterpretation and use of these attributes is left to the application
- Xthat uses them.
- X\*(Af manages user defined attributes as a structure containing
- Xthe attribute name and a (possibly empty) set of strings
- Xholding the associated attribute value(s).
- X.LP
- XAttributes can be used for very different purposes.
- XThe standard attributes are used mainly for ordering and
- Xidentifying software objects and for general management.
- XUser defined attributes will be used to store application
- Xspecific information with an ASO.
- X.LP
- XA typical example for the use of user defined attributes
- Xcan be found in the \*(sh program.
- XFor each derived object (e.g. an object file that is produced by
- Xcompiling a C source file), the name of the transformation tool
- Xand all given flags and parameters are protocoled in an
- Xattribute.
- XBesides the description of the transformation process, the name(s)
- Xand version(s) of the involved source
- Xobject(s) are recorded as list of values in another attribute.
- XThis enables \*(sh to handle recompilations in a much more
- Xsophisticated way than Make.
- X.LP
- XAnother example might be a tiny program that allows a user
- Xto associate any number of keywords with his software objects.
- XSuch a program would allow a grouping of ASOs via keywords
- Xindependently of the directory structure.
- XUser defined attributes can also be used to model references
- Xbetween ASOs.
- XAttaching the identification of the corresponding source object
- Xas attribute to a derived object actually \fIis\fR a reference.
- X.LP
- XThe full power of the concept of user defined attributes is hardly
- Xused yet but we feel that there \fIis\fR a lot of power in this approach.
- XOur first application programs use this mechanism in a
- Xstraightforward manner (illustrated in the examples above) and it works fine.
- XUser defined attributes may also be used in a more exotic way
- Xsuch as to store patches (e.g. ed scripts generated by \fIdiff\fR)
- Xto source objects.
- X.LP
- XOn the basis of user defined attributes it will further be quite
- Xeasy to construct a general object class manager that
- Xprovides an interface for the storage of typed software
- Xobjects with type specific attributes.
- XThis will be discussed in greater detail in chapter 4.
- X.NH 2
- XIdentification and Object-Keys
- X.LP
- XDue to the introduction of versions, ASOs cannot be uniquely
- Xidentified by just giving their (path-)name (like in the
- X.UX
- Xfilesystem).
- XFor the identification of attributed software objects, all attributes
- Xare considered equally qualified.
- X\*(Af is equipped
- Xwith a retrieve interface for nonunique identification of sets of ASOs.
- XA retrieve operation is driven by an attribute pattern containing
- Xall desired attribute values.
- X.LP
- XOnce identified, an ASO is represented by a unique \fIObject-key\fR
- Xby which it can be accessed further on.
- XObject keys can be fetched from a set, delivered by a retrieve
- Xoperation.
- XSelecting an object key from a set is supported by operations
- Xfor sorting sets by attribute values, recursive retrieve (a retrieve
- Xoperation with a set as search space) and building unions,
- Xintersections, or differences between two sets.
- X.KF
- X.sp 5p
- X.PS
- X boxwid = 0.6i; boxht = 0.6i; circlerad = 0.3i;
- X circle "set of" "required" "attrs."; arrow right 0.15i
- X box "AFS" "retrieve"; arrow right 0.15i
- X circle "set of" "object" "keys"; arrow right 0.15i
- X box "SELECT" "OBJECT" "KEY"; arrow right 0.15i
- XSo: circle "single" "object key"
- XGa: box "AFS" "get" "attributes" at So + 0.7i,0.4i
- XAo: box "AFS" "open" at So + 0.7i,-0.4i; arrow right 0.15i
- X circle "FILE" "descriptor"; arrow right 0.15i
- X box "file-" "system" "I/O"
- X arrow from So to Ao chop
- X arrow from So to Ga chop
- X.PE
- X.sp 5p
- X.ce
- X\fBFig. 2.3:\fR Access principle for ASOs
- X.sp 5p
- X.KE
- X.LP
- XAccess to the attributes as well as the contents on an ASO is also
- Xestablished via object keys.
- XTo access its contents, an ASO has to be opened.
- XOnce opened, the content data of an ASO can be read and written
- Xas regular
- X.UX
- Xfiles (see fig. 2.3).
- X.NH 2
- XVersion Control
- X.LP
- X\*(Af maintains a sequence of \fIrevisions\fR (successive versions)
- Xfor each design object.
- XThe numbering of revisions in a line of development is under control of
- Xthe \*(Af. Every time when a new revision is generated by saving
- Xa copy of the busy object, it is assigned a version identification of the form
- X\fIgeneration.revision\fR (e.g. 1.0 or 4.3).
- XGeneration numbers indicate major development steps that
- Xare common to all components of a complex system.
- XThe revision number serves as an update sequence number for individual
- Xcomponents within a generation.
- X.LP
- XBesides revisions, a version control system has to be able to store
- X\fIvariants\fR \- qualitatively equivalent versions differing in a
- Xcertain property \- of source objects.
- XA typical example for variants is a user interface module
- Xthat deals with different window systems.
- XUnlike the identification of revisions, where a generation.revision
- Xnumbering scheme turned out to be common sense, there is no
- Xusual variant naming scheme.
- XWe know systems, where variants are numbered, named (with single
- Xor multiple names) or both.
- X.LP
- XThe general management of variants is a major conceptual problem.
- XThe idea of variants sounds quite simple, but
- Xto actually handle them can be an extremely difficult task.
- XUp till now there doesn't seem to be a tool that conducts
- Xthe development of system variants in a really satisfying manner.
- XNevertheless we want to establish a reasonable basis for
- Xsuch a tool by providing an instructive and flexible
- Xvariant identification mechanism.
- X\*(Af supports a \fIvariant\fR attribute (a string) for each ASO.
- XThe variant attribute is totally independent from the revision
- Xnumbering, i.e. each variant is stored in its own line of development
- Xwith independent revision numbering.
- XAny structure of the variant string (e.g. multiple variant names)
- Xhas to be maintained by the application(s) [5].
- X.NH 3
- XBranches
- X.LP
- XOne major difference between the \*(Af builtin version control system
- Xand classical systems like RCS [9]
- Xand SCCS [8]
- Xis, that \*(Af establishes a user oriented view of versions
- Xthat abstracts from the physical derivation graph.
- XIn contrary to RCS and SCCS,
- Xversion histories in \*(Af are essentially linear.
- XLogically, new versions are always appended to the end of the
- Xversion history.
- XUpdates of older versions can be attached as leaves (not branches)
- Xto the line of development (see fig 2.5).
- XVariants are stored in parallel lines of development.
- X.LP
- XAt first glance, it looks like a loss of functionality of the \*(Af
- Xversion control system
- Xcompared to systems like RCS or SCCS (where are the branches).
- XA closer look shows, that there is only a different identification
- Xscheme.
- X.LP
- XFigures 2.4 and 2.5.
- Xshow the same number of revisions/variants developed in the same way.
- XThe first figure shows a RCS version tree and the second
- Xshows its \*(Af pendant.
- X.KF
- X.sp 5p
- X.PS
- X circlerad = 0.25i;
- X box ht 3.1i wid 5.8i; move to 0.3i,0;
- XC1: circle "1.1"; arrow right 0.5i
- XC2: circle "1.2"; arrow right 0.5i
- XC3: circle "1.3"; arrow right 0.5i
- XC4: circle "2.1"; arrow right 0.5i
- XC5: circle "2.2"
- XC6: circle "1.1.1.1" at C1 + 0.5i,0.6i; arrow from C1 to C6 chop
- XC7: circle "1.2.1.1" at C2 + 0.5i,0.6i; arrow from C2 to C7 chop
- XC8: circle "1.3.1.1" at C3 + 0.5i,0.6i; arrow from C3 to C8 chop
- XC9: circle "1.2.3.1" at C2 + 0.5i,-0.6i; arrow from C2 to C9 chop
- X move to right of C9; arrow right 0.4i;
- XC0: circle "1.2.3.2"; arrow right 0.4i; circle "1.2.3.3"
- XCa: circle "1.2.2.1" at C2 + 0.3i,1.2i; arrow from C2 to Ca chop
- X move to right of Ca; arrow right 1.8i; circle "1.2.2.2"
- XCb: circle "1.2.3." "2.1.1" at C0 + 0.4i,-0.6i; arrow from C0 to Cb chop
- X.PE
- X.sp 5p
- X.ce
- X\fBFig. 2.4:\fR RCS version tree
- X.sp 5p
- X.KE
- X.KF
- X.sp 5p
- X.PS
- X circlerad = 0.25i;
- X move to 0,0.3i; box ht 1.3i wid 5.9i
- X move to 0,1.4i; box ht 0.7i wid 5.9i
- X move to 0,-1.1i; box ht 1.3i wid 5.9i; move to 0.3i,0;
- XC1: circle "1.0"; arrow right 0.5i
- XC2: circle "1.1"; arrow right 0.5i
- XC3: circle "1.2 / 2.0"; arrow right 0.5i
- XC4: circle "2.1"; arrow right 0.5i
- XC5: circle "2.2"
- XC6: circle "1.0" "fix1" at C1 + 0.5i,0.6i; arrow from C1 to C6 chop
- XC7: circle "1.1" "patch1" at C2 + 0.5i,0.6i; arrow from C2 to C7 chop
- XC8: circle "1.2" "fix1" at C3 + 0.5i,0.6i; arrow from C3 to C8 chop
- X circle "1.0" "X" at C2 + 0.3i,1.4i; arrow right 1.8i; circle "1.2" "X"
- XC9: circle "1.1" "NeWS" at C2 + 0.5i,-1.4i; arrow right 0.4i;
- XC0: circle "1.2 / 2.0" "NeWS"; arrow right 0.4i; circle "2.1" "NeWS"
- XCb: circle "1.2" "NeWS" "fix1" at C0 + 0.5i,0.6i; arrow from C0 to Cb chop
- X.PE
- X.sp 5p
- X.ce
- X\fBFig. 2.5:\fR AFS lines of development
- X.sp 5p
- X.KE
- X.LP
- XThe version identification scheme of \*(Af abstracts from the
- Xphysical evolution of the single versions
- X(nevertheless, the physical links are there and maintained in
- Xa way similar to RCS).
- XRCS and SCCS present a data structure oriented view
- Xof version histories to the user.
- XSome nasty problems arise from mixing
- Xlogical and physical derivation graph in respect to numbering/naming
- Xof revisions.
- XFirst, version numbers in branches get very complex (four or more numbers)
- Xwhich is not very instructive. Second, although there are \(lqso many
- Xnumbers\(rq there is no generation number in branches !
- X.LP
- XConceptually, \*(Af does not support arbitrary branching.
- XBranching off the main line of development happens most of the time
- Xbecause a developer wants to
- X.IP \(bu 0.2i
- Xcreate a variant or
- X.IP \(bu
- Xstore modifications of older versions (bug-fixes or customizations) or
- X.IP \(bu
- Xmake experimental changes that should not necessarily
- Xgo into the main line of development.
- X.RE
- X.LP
- XThe first case should be realized by parallel lines of development.
- XThe latter two cases are not explicitly supported by
- X\*(Af itself.
- XA solution has to be given by an application program
- Xeither based on an extended use of
- Xthe \fIvariant\fR attribute or on storing patches in
- Xuser defined attributes.
- X.NH 3
- XThe version status model
- X.LP
- XAs a consequence of the original design of \*(Af as part of a
- Xsoftware development environment,
- X\*(Af provides a status model for saved source objects to support the
- Ximplementation of a general project organization scheme.
- XThe project organization scheme we have in mind
- Xdistinguishes between private workspaces for each participating
- Xprogrammer, and a central project database, where all the serious
- Xresults of the programmers' efforts are collected.
- X.LP
- XThe basic status model that is built into the version control system
- Xrecognizes the following states:
- X.IP \fBbusy\fR 0.8i
- XThe object is under development and its contents may
- Xbe changed.
- X.IP \fBsaved\fR
- XThe object is saved and may be used for later backup.
- X.IP \fBproposed\fR
- XThe object has been submitted for publication by the developer
- Xbut still needs formal approval by a quality assurance board
- Xto become publically visible and accessible in the official
- Xdatabase.
- X.IP \fBpublished\fR
- XThe object has passed the formal approval and is now accessible to
- Xevery member of the project. It is not yet accessed and may therefore
- Xbe withdrawn if necessary.
- X.IP \fBaccessed\fR
- XThe object has been published, and is now
- Xaccessed by some members of the project.
- X.IP \fBfrozen\fR
- XThe object may be part of a system configuration
- Xthat has been released to the outside world. This means it must under
- Xno circumstances be destroyed.
- X.RE
- X.NH 1
- XRealization
- X.LP
- XCurrently, we have two different implementations of \*(Af (in
- Xdifferent development stages).
- XOne on top of the
- X.UX
- Xfilesytem and another one on top of \*(Da,
- Xa dedicated software engineering database [1].
- XBoth are written in C and provide a library interface.
- XFurther developments will be made in C++ and we will implement
- Xa new interface in C++.
- X.LP
- XThe interface of both implementations is nearly identical.
- XDifferences exist only in marginal routines concerning the data
- Xmanagement. For example has the \*(Da implementation additional
- Xroutines for opening and closing the database.
- X.NH 2
- XThe Interface
- X.LP
- XThe main datatypes of \*(Af are:
- X.IP \(bu 0.2i
- XThe \fIobject key\fR that uniquely identifies a software object.
- XThe structure of this type is different in the two different
- Ximplementations. Consequently, application programs should handle
- Xthis type as opaque type and should not access single fields
- X(unfortunately this is a little bit clumsy in C \- an implementation
- Xas C++ class would be more appropriate).
- X.IP \(bu
- X\fISet descriptors\fR represent a set of object keys.
- XA set descriptor contains information about the number of keys
- Xin the set and a pointer to a list of object keys.
- X.IP \(bu
- XAn \fIAttribute buffer\fR which is capable to hold all attributes of a
- Xsoftware object (standard attributes and user defined attributes).
- XAttribute buffers have two different purposes.
- XFirst, they can hold a retrieve pattern, i.e. they
- Xmay be (partially) filled with \fIdesired\fR attribute
- Xvalues and then be passed as argument to a retrieve operation.
- XSecond, an attribute buffer is used to return all attributes of
- Xan identified ASO on demand.
- X.RE
- X.LP
- XThe names of all operations of the \*(Af are preceded by \fIaf_\fR
- X(e.g. \fIaf_saverev\fR).
- XIn the following sections, the most important (most interesting)
- Xfunctions of \*(Af are described.
- X.NH 3
- XRetrieval
- X.LP
- X\*(Af provides two different retrieval operations, \fIaf_find\fR and
- X\fIaf_bpfind\fR. The first does retrieval of source objects and
- Xthe second of derived objects.
- XBoth have to be parameterized with an attribute buffer containing
- Xa retrieve pattern and both return a set holding the keys of all
- XASOs matching the specified attribute pattern.
- X.LP
- XDue to the possibility to uniquely identify source objects by the
- Xattributes \fIhostname, syspath, name, type, generation, revision\fR
- Xand \fIvariant\fR, there is a shortcut (faster) operation to get the
- Xkey of well known object by specifying values for these seven
- Xattributes. The name of the function is \fIaf_getkey\fR and it returns
- Xan object key if the sought software object exists.
- X.NH 3
- XSets
- X.LP
- X\*(Af contains a considerable number of operations on sets.
- XAlthough a set contains \fIobject keys\fR and not complete
- Xobjects, we speak of \(lqobjects in a set\(rq throughout this
- Xchapter for reasons of simplicity.
- X.LP
- X\fIAf_sortset\fR sorts the objects in a set in respect to the
- Xvalue of a single or compound attribute.
- XFor example, objects can be ordered alphabetically by their
- Xname attribute which is a single attribute.
- XA typical compound attribute is the \fIversion number\fR
- Xconsisting of generation number and revision number
- X(generation.revision).
- XBesides standard attributes one can pass any name of a user defined
- Xattribute as argument to \fIaf_sortset\fR.
- XThis works, even if the attribute is not defined for every
- Xobject in the set.
- X.LP
- XThe call \fIaf_subset\fR performs a recursive retrieve operation on
- Xan existing set. \fIAf_subset\fR is (like \fIaf_find\fR)
- Xparameterized with an attribute buffer containing a retrieve pattern.
- XIt results in a subset of the original set.
- X.LP
- XOther set commands provide
- Xadding and deleting single objects to/from sets as well as
- Xbuilding intersections, unions and differences of two existing sets.
- X.NH 3
- XReading and Manipulating Attributes
- X.LP
- XThe manipulation of standard attributes for software objects
- Xis under strict control of \*(Af.
- XMany standard attributes can only be modified implicitly
- Xby performing a \*(Af operation.
- XThe other standard attributes can only be manipulated in
- Xa well defined manner.
- X.LP
- XThe attributes \fIhostname, system path, name\fR and \fItype\fR
- Xare immutable for saved objects (source or derived).
- XThey are set once (at saving time) as inherited from the filesystem
- Xlocation of the file the object evolved from.
- XAs busy objects are regular
- X.UX
- Xfiles, they can be renamed by linking them to another place in
- Xthe filesystem.
- X.LP
- XVersion number and the version state are only relevant
- Xfor source objects.
- XA source object is automatically assigned a version number and state
- X\fIsaved\fR when it is
- Xgenerated. The version number can subsequently only be increased
- X(set to a logically bigger number, e.g. from 1.2 to 1.4 or from
- X2.3 to 3.0).
- XThe version state can be set to the logically following or
- Xpreceding (see states list in 2.4) state but it can never be
- Xreset to \fIbusy\fR.
- XBusy objects have no version number
- Xand are always in state \fIbusy\fR.
- XVersion number and state
- Xof derived objects can be set arbitrarily (but \*(Af does not
- Xcare about their values).
- X.LP
- XThe management of user defined attributes is entirely controlled by
- Xthe application program.
- XAn application program called by the owner
- Xor the author of an ASO can arbitrarily add, delete and modify
- Xthese attributes.
- X\*(Af supports the management of user defined attributes
- Xby storing them as name/value(s) pairs.
- XA name (string) is associated with any number (zero to infinite)
- Xof values (strings).
- XThe function \fIaf_sudattr\fR allows the addition and deletion
- Xof whole attribute entries and single values.
- X.NH 3
- XLocking
- X.LP
- XThe locking mechanism for reserving update rights in a line
- Xof development is reflected by the functions \fIaf_lock, af_unlock\fR
- Xand \fIaf_testlock\fR.
- XCalling the function \fIaf_lock\fR, causes the identified ASO
- Xto be locked by the caller, provided the object was available
- Xfor locking.
- X.LP
- X\fIAf_testlock\fR returns the user ID of the lock holder (if present).
- XLocks can either be released by the lock holder of the design
- Xobject or be broken by the owner by means of \fIaf_unlock\fR.
- X.NH 3
- XVersion Control
- X.LP
- XThe version control system has been described in detail earlier in this paper.
- XThe most important operations are \fIaf_saverev\fR and \fIaf_savebinary\fR
- Xwhich create a copy of the given, busy, ASO and store it as
- Xnew source resp. derived version.
- X.LP
- X\fIAf_newgen\fR increases the generation number in a line of development.
- XIt creates a pseudo revision which is identical to the last saved revision
- Xand attaches a new version number to it.
- XThe generated pseudo revision has the character of an alias (see also
- Xfigure 2.5).
- XThe new version number is generated by increasing the generation number by 1
- Xand resetting the revision number to 0 (e.g. 1.4 becomes 2.0).
- X.LP
- XIf the busy object of a line of development was replaced by another file,
- Xfor example an older version or a variant,
- X\fIaf_setbusy\fR should be called with the key of the
- Xold busy object and that of the new one, to inform \*(Af about the change.
- XThis is necessary to keep track of the physical derivation structure of
- Xa line of development which is substantially for an efficient delta
- Xtechnique.
- X.NH 3
- XFilesystem Primitives
- X.LP
- X\fIAf_open\fR and \fIaf_close\fR are
- Xfilesystem primitives analogous to the
- X.UX
- Xcalls \fIfopen\fR and \fIfclose\fR.
- XThe only difference is, that \fIaf_open\fR takes an object key instead
- Xof a pathname as input parameter.
- X\fIAf_open\fR returns a pointer to a \fIFILE\fR structure, so that
- Xthe application program can use the whole
- X.UX
- Xstdio interface on ASOs.
- X.LP
- XAdditionally, ASOs can be created and removed (unlinked).
- XDerived files residing in a binary pool can be restored
- Xat their former position with \fIaf_restore\fR.
- X.LP
- XThe interface is completed by a number of miscellaneous
- Xroutines.
- XThese are routines for error reporting and cleaning up
- X(removing tmp files and freeing memory) as well as functions
- Xfor splitting up
- X.UX
- Xpathnames in the \*(Af attributes syspath, name and type.
- X.NH 2
- X\*(Af on top of the
- X.UX
- Xfilesystem
- X.LP
- XThe first implementation of \*(Af was done on top of the
- X.UX
- Xfilesystem.
- XThis implementation is ready and in use.
- X.LP
- XSaved ASOs are stored in archive files (like SCCS and RCS). \*(Af
- Xmaintains two archive files for each line of development of source
- Xobjects \- one holding the attributes and the other holding the data.
- X\*(Af stores its archives in a subdirectory called \*(Af. If the
- Xarchives shall be stored elsewhere but not in a subdirectory, an \*(Af
- Xapplication can set an \fIarchive path\fR to specify the name of a
- Xdirectory where all subsequently accessed or created archives are
- Xstored. In this case, the application program
- Xis responsible for maintaining the relative\-path relationship
- Xbetween a busy object and the corresponding archive.
- X.LP
- XTo save disk space,
- XSuccessive versions in a line of development are stored as deltas
- X(differences to the previous version).
- XFor generating file deltas a new delta technique,
- Xdescribed in [7]
- Xis employed.
- XDeltas computed by this method are about 30 percent smaller than deltas
- Xgenerated by \fIdiff\fR (the standard
- X.UX
- Xfile comparison tool).
- XThis delta technique uses characters rather than lines as atomic symbols.
- X.LP
- XWe use a backward delta technique (like RCS),
- Xi.e. only the most recent version of each line of development is
- Xstored completely.
- XOlder versions can be reconstructed by successively applying
- Xall deltas from the most recent to the desired version.
- XIn the filesystem implementation, deltas between parallel lines of
- Xdevelopment are not supported (conceptually, they should be there).
- XThis is because different lines of development are stored in
- Xdifferent archive files and we consider it too risky
- Xto spread delta chains across different
- X.UX
- Xfiles.
- XIf the coherence of the two files gets lost (this may happen by simply
- Xmoving one file) and the chain gets broken, some revisions may
- Xnot be reproducible any more.
- X.LP
- XDerived files are stored physically unchanged.
- XTests with our delta technique showed, that it makes not much
- Xsense to build deltas between binary files.
- XOn calling \fIaf_savebinary\fR, the identified file is linked into the
- X\*(Af subdirectory.
- XAdditionally, the attribute buffer containing all the attributes
- Xfor the derived file is stored in a \fIndbm\fR Database.
- X.LP
- XIf a saved source object shall be opened,
- Xit is reconstructed and stored in a temporary file.
- XDue to the unalterability of saved ASOs, the temporary file is simply
- Xremoved on closing (changes have no effect on the stored ASO).
- XIf one really wants to reconstruct a file, one has to create a
- Xbusy object, read the data from the tmp file and write it to the
- Xcreated busy object.
- X.NH 2
- X\*(Af on top of \*(Da
- X.LP
- XThe \*(Af implementation on top of \*(Da, is currently
- Xunder development.
- XIn this implementation, saved revisions and binary pools are stored
- Xin the database.
- X.LP
- XIn the current implementation, the database is only used for storing the
- Xinternal data (archives and binary pools) of \*(Af.
- XBusy objects and temporary files (containing the data of reconstructed
- Xolder versions) are still stored in the
- X.UX
- Xfilesystem.
- X\*(Af applications have no direct access to the database.
- XSimilar to the filesystem implementation, the contents of an ASO
- Xhas the form of a byte stream.
- XUp till now, there is no substantial difference of this impementation
- Xto the filesystem implementation except that it will be slower.
- X.LP
- XThe actual enhancement of \*(Af on \*(Da will be the possibility for
- Xapplications to use the structuring facilities of the database
- Xfor their internal data (the content data of ASOs).
- XBut how shall a specific ASO be created, copied, or opened, and how
- Xshould a delta between two versions be constructed ?
- XQuestions that can only be answered when the contents structure of the
- Xcorresponding ASO is known.
- XThis problem can only be solved satisfactorily by following an
- Xobject oriented approach.
- XAn \*(Af implementation taking this approach will provide a mechanism
- Xfor the definition of ASO classes, defining specific attributes
- Xand virtual operations (e.g. compute delta, open, linearize)
- Xon instances of these classes.
- X.LP
- XAnother very practical problem is extensibility. In the current
- Xstate, a \*(Da database has \fIone\fR schema where all database
- Xobject types have to be defined.
- XAddition of a new application with the necessity of schema
- Xupdates requires the generation of an entire new database and the
- X(troublesome)
- Xtransfer of all the data from the old database to the new one.
- X.NH 1
- XThe future of \*(Af
- X.LP
- XWhen we made the first design of \*(Af,
- Xaimed primarily at facilitating the implementation of the
- X\*(sh\-toolkit,
- Xwe were not aware of the power of this approach.
- XEspecially the mechanism of user defined attributes
- Xinspired us to think of applications that go far beyond
- Xthe tasks \*(Af was originally designed for.
- X.LP
- XHowever, it is still a problem to make consistent use of user
- Xdefined attributes. Each application has to set them explicitly.
- XThe exchange of information via user defined attributes
- Xhas to be subject of special agreements and naming conventions.
- XA good improvement will be the introduction of some kind of
- XASO definition language.
- XThis would be the input for a general class manager
- Xthat manages the storage of objects of well defined object classes.
- XThe definition of an object class contains a specification
- Xof all attributes attached to an object of this class.
- XThe object classes will be part of a
- Xclass hierarchy with attribute inheritance.
- XThis makes
- X\*(Af a basis for object\-oriented software engineering applications
- Xthat deal with software objects.
- XThese are able to store
- Xtheir objects persistently, identify them (uniquely) and share them
- Xwith other applications.
- X.LP
- XSubsequently we want to give an idea,
- Xhow a possible class hierarchy might look like.
- XExamples for classes are \fIsoftware object\fR,
- X\fIsource object\fR, \fIderived object\fR or \fIrevisible object\fR.
- XThe class \fIsoftware object\fR is the basic class.
- XAll other classes are derived classes inheriting the attributes
- Xof \fIsoftware object\fR.
- X\fISource objects\fR and \fIderived objects\fR
- Xare direct subclasses of \fIsoftware object\fR.
- X\fIRevisible source object\fR would be a subclass of
- X\fIsource objects\fR with the additional attributes
- X\fIgeneration number, revision number\fR and \fIversion state\fR.
- XAn example for defining a class hierarchy
- Xfor an object oriented database can be found in [11].
- X.LP
- XAnother important topic is support for \*(Af
- Xapplications distributed over a local area network.
- XTo support this, we need \fIpersistent keys\fR.
- XUnlike the current realization of object keys which are
- Xonly valid during the lifetime of the application process,
- Xpersistent keys are interchangeable between processes
- Xand machines.
- X.NH 1
- XConclusion
- X.LP
- XProperly speaking, \*(Af was invented by accident.
- XWe needed a basic data storage system capable to hold the
- Xsoftware objects we deal with, plus some information about them
- Xfor use by our software configuration management toolkit.
- XAfter having made about 200 attempts\(dg
- X.FS
- X\(dg Actually we made only four or five, but 200 sounds better
- X.FE
- Xto finally fix the set of attributes necessary to hold
- Xsufficient information about
- Xsoftware objects, we gave up and invented the user
- Xdefined attributes instead.
- XOne important inspiration for user defined attributes was the
- Xenvironment concept known from the
- X.UX
- Xshell.
- XOnce available, the environment is extended by some new variable
- Xalmost each time a new tool is added to the system.
- X.LP
- XSo we defined \*(Af as an internal interface.
- XWhile writing our first \*(Af applications, we got aware of
- Xthe power and the insufficiencies of the mechanism of
- Xapplication defined attributes.
- XWe believe that many applications might benefit from this concept,
- Xand that it is too valuable to be just an internal interface.
- XFurther development of \*(Af will primarily go into the direction
- Xdescribed in the previous chapter.
- XWe are curious, where this way will lead us to.
- 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.KS
- X.]<
- X.\"Dittrich.K-1986-1
- X.ds [F 1
- 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.\"Feldman.S.I.-1979-2
- X.ds [F 2
- 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.\"Leblang.D.B.-1985-3
- X.ds [F 3
- X.]-
- X.ds [A David B. Leblang
- X.as [A " and Gordon D. McLean, Jr.
- X.ds [T Configuration Management for Large-Scale Software Development Efforts
- X.ds [P 122-127
- X.nr [P 1
- X.ds [I GTE Laboratories
- X.ds [J Workshop on Software Engineering Environments for
- X.as [J " Programming-in-the-Large
- X.ds [C Harwichport, Massachusets
- X.ds [D June 1985
- X.nr [T 0
- X.nr [A 1
- X.nr [O 0
- X.][ 1 journal-article
- X.\"Mahler.A-1988-4
- X.ds [F 4
- 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.\"Mahler.A-1988-5
- X.ds [F 5
- X.]-
- X.ds [A Axel Mahler
- X.as [A " and Andreas Lampen
- X.ds [T A Toolkit for Software Configuration Management
- X.ds [J Proceedings of the Spring 1988 EUUG Conference
- X.ds [I European Unix systems User Group
- X.ds [P 185-202
- X.nr [P 1
- X.ds [C London, UK
- X.ds [D April 1988
- X.nr [T 0
- X.nr [A 0
- X.nr [O 0
- X.][ 1 journal-article
- X.\"Nestor.J.R.-1986-6
- X.ds [F 6
- X.]-
- X.ds [A John R. Nestor
- X.ds [T Toward a Persistent Object Base
- X.ds [J International Workshop on Advanced Programming Environments
- X.ds [J Lecture Notes in Computer Science
- X.ds [C Trondheim, Norway
- X.ds [P 372-394
- X.nr [P 1
- X.ds [I Springer Verlag
- X.ds [D June 1986
- X.nr [T 0
- X.nr [A 0
- X.nr [O 0
- X.][ 1 journal-article
- X.\"Obst.W-1987-7
- X.ds [F 7
- 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.\"Rochkind.M.J.-1975-8
- X.ds [F 8
- 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-9
- X.ds [F 9
- 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-10
- X.ds [F 10
- 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.\"Zdonik.S.B.-1986-11
- X.ds [F 11
- X.]-
- X.ds [A Stanley B. Zdonik
- X.ds [T Version Management in an Object-Oriented Database
- X.ds [J Lecture Notes in Computer Science
- X.ds [J International Workshop on Advanced Programming Environments
- X.ds [C Trondheim, Norway
- X.ds [P 405-422
- X.nr [P 1
- X.ds [I Springer Verlag
- X.ds [D June 1986
- X.nr [T 0
- X.nr [A 0
- X.nr [O 0
- X.][ 1 journal-article
- X.]>
- X.KE
- END_OF_FILE
- if test 46807 -ne `wc -c <'papers/lisbon.ms'`; then
- echo shar: \"'papers/lisbon.ms'\" unpacked with wrong size!
- fi
- # end of 'papers/lisbon.ms'
- fi
- echo shar: End of archive 30 \(of 33\).
- cp /dev/null ark30isdone
- 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
-