version models for software configuration...

Version Models for Software Configuration ManagementREIDAR CONRADI

Norwegian University of Science and Technology, Trondheim

AND

BERNHARD WESTFECHTEL

Aachen University of Technology

After more than 20 years of research and practice in software configurationmanagement (SCM), constructing consistent configurations of versioned softwareproducts still remains a challenge. This article focuses on the version modelsunderlying both commercial systems and research prototypes. It provides anoverview and classification of different versioning paradigms and defines andrelates fundamental concepts such as revisions, variants, configurations, andchanges. In particular, we focus on intensional versioning, that is, construction ofversions based on configuration rules. Finally, we provide an overview of systemsthat have had significant impact on the development of the SCM discipline andclassify them according to a detailed taxonomy.

Categories and Subject Descriptors: D.2.2 [Software Engineering]: Tools andTechniques—computer-aided software engineering; D.2.6 [Software Engineering]:Programming Environments; D.2.9 [Software Engineering]:Management—software configuration management; H.2.3 [DatabaseManagement]: Languages—database (persistent) programming languages; H.2.8[Database Management]: Database Applications; I.2.3 [Artificial Intelligence]:Deduction and Theorem Proving—deduction, logic programming

General Terms: Languages, Management

Additional Key Words and Phrases: Changes, configuration rules, configurations,revisions, variants, versions

1. INTRODUCTION

Software configuration management(SCM) is the discipline of managing theevolution of large and complex softwaresystems [Tichy 1988]. The importance ofSCM has been widely recognized, asreflected in particular in the Capability

Maturity Model (CMM) developed bythe Software Engineering Institute(SEI) [Humphrey 1989; Paulk et al.1997]. CMM defines levels of maturityin order to assess software developmentprocesses in organizations. Here SCM isseen as one of the key elements for

This work was partially performed during a sabbatical in which the second author spent Augustthrough October 1995 in Trondheim. Support from NTNU is gratefully acknowledged.Authors’ addresses: R. Conradi, Department of Computer and Information Science, Norwegian Univer-sity of Science and Technology (NTNU), N-7034 Trondheim, Norway; B. Westfechtel, Department ofComputer Science III, Aachen University of Technology, D-52056 Aachen, Germany.Permission to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1998 ACM 0360-0300/98/0600–0232 $05.00

ACM Computing Surveys, Vol. 30, No. 2, June 1998

moving from “initial” (undefined pro-cess) to “repeatable” (project manage-ment, SCM, and quality assurance havecome into operation). Furthermore,SCM plays an important role in achiev-ing ISO 9000 conformance.

SCM serves different needs [Feiler1991a].

—As a management support discipline,SCM is concerned with controllingchanges to software products. It isthis view of SCM that is addressed inthe classical textbook by Bersoff et al.[1980] and the IEEE standard [IEEE1983; IEEE 1988]. According to thelatter, SCM covers functionalitiessuch as identification of product com-ponents and their versions, change

control (by establishing strict proce-dures to be followed when performinga change), status accounting (record-ing and reporting the status of compo-nents and change requests), and auditand review (quality assurance func-tions to preserve product consistency).Thus SCM is seen as a support disci-pline for project managers.

—As a development support discipline,SCM provides functions that assistdevelopers in performing coordinatedchanges to software products. Thisview of SCM is described, for exam-ple, in the textbook by Babich [1986].To support developers, SCM is incharge of accurately recording thecomposition of versioned softwareproducts evolving into many revisionsand variants, maintaining consis-tency between interdependent compo-nents, reconstructing previously re-corded software configurations,building derived objects (compiledcode and executables) from theirsources (program text), and construct-ing new configurations based on de-scriptions of their properties.

In this article, SCM is primarily con-sidered a development support disci-pline. We provide an overview of versionmodels implemented both in commercialsystems and research prototypes. A ver-sion model defines the objects to be ver-sioned, version identification and orga-nization, as well as operations forretrieving existing versions and con-structing new versions. Software objectsand their relationships constitute theproduct space, their versions are orga-nized in the version space. A versionedobject base combines product and ver-sion space. A specific version model ischaracterized by the way the versionspace is structured, by the decision ofwhich objects are versioned both exter-nally (from the user’s point of view) andinternally (within the versioned objectbase), by the relationships among ver-sion spaces of different objects, and bythe way reconstruction of old and con-struction of new versions are supported.

CONTENTS1. INTRODUCTION2. PRODUCT SPACE

2.1 Software Objects2.2 Relationships2.3 Representations of the Product Space

3. VERSION SPACE3.1 Versions, Versioned Items, and Deltas3.2 Extensional and Intensional Versioning3.3 Intents of Evolution: Revisions, Variants, and

Cooperation3.4 Representations of the Version Space: Version

Graphs and Grids3.5 State-Based and Change-Based Versioning

4. INTERPLAY OF PRODUCT SPACE AND VERSIONSPACE4.1 AND/OR Graphs4.2 Granularity of Versioning4.3 Deltas4.4 Relations Between Version Model and Data

Model5. INTENSIONAL VERSIONING

5.1 Problem: Combinability Versus ConsistencyControl and Manageability

5.2 Conceptual Framework for Intensional Version-ing

5.3 Configuration Rules5.4 Configurators: Tools for Evaluating Configura-

tion Rules5.5 Merge Tools

6. VERSION MODELS IN SCM SYSTEMS6.1 Overview6.2 Taxonomy-Based Classification6.3 Descriptions of SCM Systems

7. RELATED WORK7.1 Related Work on Version Models7.2 Related Disciplines

8. CONCLUSION

Version Models • 233


SCM systems express version modelsin varying ways. Many systems, includ-ing most commercial ones [Rigg et al.1995], are file-based and apply version-ing to files and directories [Rochkind1975; Tichy 1985; Fowler et al. 1994].Various language-based approacheshave been developed as well based onmodular programming languages [Lamp-son and Schmidt 1983b], module inter-connection languages [Prieto-Diaz andNeighbors 1986], or system modelinglanguages [Marzullo and Wiebe 1986].These languages are typically used torepresent versions of modules and rela-tionships such as imports, include de-pendencies, and the like. Finally, sev-eral SCM systems are founded ondatabases and manage versions of ob-jects and relationships stored in the da-tabase. Different data models have beenused, including EER [Dittrich et al.1986; Oquendo et al. 1989], object-ori-ented [Estublier and Casallas 1994],and deductive [Zeller and Snelting1995] ones.

The variety of formalisms makes itdifficult to compare the version modelsof different SCM systems with one an-other. In addition, each system comeswith its own terminology. On the otherhand, the underlying concepts are oftenvery similar. In order to reveal theseconcepts, we introduce a unified termi-nology. Furthermore, to describe ver-sion models in a uniform, “canonical”formalism, we use graphs at manyplaces in the article. A graph consists ofnodes and edges representing entitiesand (binary) relationships, both ofwhich may be decorated with attributes.Graphs are well suited to represent theorganization of a versioned object base,even if the corresponding system is notgraph-based. For example, SCCS [Roch-kind 1975] and RCS [Tichy 1985] areboth file-based, but the version space ofa text file may be represented naturallyas a version graph. Other formalismsare used as required, such as textuallanguages for expressing configurationrules.

The main contribution of this article

is to give definitions and introduce ataxonomy. Furthermore, it provides asurvey of the current state of the art bydescribing SCM systems in a unifiedterminology and classifying them ac-cording to the taxonomy. In this way, itprepares the ground for developing auniform version model, that is, a com-mon framework in which specific ver-sion models may be expressed. A uni-form model would assist developers notonly in constructing SCM systems butalso in tailoring them more flexibly tothe needs of their users. Multiple para-digms could be supported in parallel,allowing users to switch back and forthas required. Furthermore, as noted inBrown et al. [1991], a uniform modelwould constitute a common foundationfor integrating heterogeneous SCM sys-tems in a federated architecture.

In the interest of a thorough discus-sion, we focus on core issues of version-ing, namely, the organization of the ver-sion space, the interrelations of productspace and version space, and the con-struction of consistent configurations.Other issues considered essential partsof SCM are only discussed briefly, inparticular, management of workspaces,construction of derived objects, coopera-tion, and distribution: all these issuesare related to version management, butelaborating on them goes beyond thescope of this article.

The article is structured as follows.Before introducing versions, the productspace is described in Section 2. Subse-quently, we discuss the version spacewithout making any assumptions aboutthe product space (Section 3). The inter-play of product and version space isaddressed in Section 4. Section 5 is de-voted to intensional versioning (i.e., con-struction of versions based on rules de-scribing consistent combinations).Section 6 provides an overview of sys-tems that have had significant impacton the development of the SCM disci-pline. Related work is discussed in Sec-tion 7, and a short conclusion is given inSection 8.

234 • R. Conradi and B. Westfechtel


2. PRODUCT SPACE

The product space describes the struc-ture of a software product without tak-ing versioning into account (in otherwords, we assume only one version of asoftware product). The product spacecan be represented by a product graphwhose nodes and edges correspond tosoftware objects and their relationships,respectively. Different version modelsvary in their assumptions with respectto the product space. These differencesrefer to the types of software objectsand relationships, to the granularity ofobject representations, and to the se-mantic levels of modeling.

2.1 Software Objects

A software object records the result of adevelopment or maintenance activity.An SCM system has to manage all kindsof software objects created throughoutthe software life cycle, including re-quirements specifications, designs, doc-umentations, program code, test plans,test cases, user manuals, project plans,and the like.

Identification is an essential functionprovided by SCM. Thus, each softwareobject carries an object identifier (OID)that serves to identify it uniquelywithin a certain context. An externalOID is a name assigned by the user,whereas a system-generated, uniqueOID may be used internally.

Software objects are rather coarse-grained units that are structured inter-nally. For example, a program module iscomposed of declarations and state-ments, and a documentation consists ofsections and paragraphs. Thus a soft-ware object is composed of more fine-grained units.

The data model used for representingthe product space may or may not dis-tinguish explicitly between coarse-grained and fine-grained units. Forexample, file systems make this distinc-tion, whereas many object-oriented datamodels represent coarse- and fine-grained units in a uniform way. In the

following, we represent the contents ofsoftware objects in long attributes at-tached to nodes of the product graph.

Software objects may have differentrepresentations, depending on the typesof tools operating on them. In toolkitenvironments, software objects arestored as text files [Rochkind 1975]. Incontrast, syntax trees [Habermann andNotkin 1986] or graphs [Nagl 1996] areused in structure-oriented environ-ments. As discussed later, these repre-sentations influence the functionality ofan SCM system. For example, a diffcommand for comparing two versions ofa program module returns differing textlines in the case of text files and differ-ing syntactic units in the case of syntaxtrees, respectively.

Independently of the representationchosen for software objects, we may dis-tinguish between domain-independentand domain-specific models of the prod-uct space. Domain-independent modelsmake no assumptions about the types ofsoftware objects to be maintained. Allsoftware objects produced throughoutthe whole software lifecycle project aresubject to version control [Tichy 1985].Domain-specific models are tailored to-wards specific types of software objects(e.g., abstract data types in algebraicspecifications) [Ehrig et al. 1989].

2.2 Relationships

Software objects are connected by vari-ous types of relationships. Compositionrelationships are used to organize soft-ware objects with respect to their gran-ularity. For example, a software productmay be composed of subsystems, whichin turn consist of modules. Objects thatare decomposed are called composite ob-jects or configurations. Objects residingat the leaves of the composition hierar-chy are denoted atomic objects. Notethat an “atomic” software object is stillstructured internally; that is, it has afine-grained content. The root of a com-position hierarchy is called the (soft-ware) product.

The semantics of composite objects



varies significantly across differentmodeling approaches. Furthermore, aspecific approach may support customi-zable semantics. As a least common de-nominator, a composite object is definedas an object o that represents a sub-graph of the product graph. All objectsthat are transitively reachable from ovia composition relationships belong tothis subgraph. There may be structuralconstraints with respect to the composi-tion hierarchy (trees, DAGs), and theexistence of a component may dependon the existence of its superobject(s).Furthermore, there may be constraintswith respect to long attributes (e.g.,long attributes may be attached only toleaves of the composition hierarchy). Fi-nally, a composite object may act as aunit with respect to structural opera-tions (e.g., copy or delete), abstraction(encapsulation of components), concur-rency control (locking of a compositeobject includes locking of its compo-nents), and version control.

Dependency relationships (simplycalled dependencies in the following) es-tablish directed connections between ob-jects that are orthogonal to compositionrelationships. They include, for exam-ple, lifecycle dependencies between re-quirements specifications, designs, andmodule implementations, import or in-clude dependencies between modules,and build dependencies between com-piled code and source code.

The source and the target of a depen-dency correspond to a dependent and amaster object, respectively. A depen-dency implies that the contents of thedependent must be kept consistent withthe contents of the master. Thus thedependent may have to be changedwhen the master is modified.

Software objects are further classifiedinto source objects and derived objects. Asource object is created by a human whois supported by interactive tools, for ex-ample, text editors or graphical editors.A derived object is created automati-cally by a tool, for example, a compileror linker. Note that the classification ofa software object as a source or derived

object depends on the available tool sup-port. Furthermore, software objects maybe partially derived and be partiallyconstructed manually. For example, theskeleton of a module body may be cre-ated automatically from its interfaceand subsequently filled in by a pro-grammer.

The process of creating derived ob-jects from source and other derived ob-jects is called system building. The ac-tions to be performed are specified bybuild rules. The build tool has to ensurethat build steps corresponding to theserules are executed in the correct order;that is, build dependencies must betaken into account. In contrast, sourcedependencies represent relationshipsbetween source objects (e.g., lifecycledependencies as mentioned previously).

2.3 Representations of the Product Space

Figure 1 illustrates different represen-tations of a sample software product foowhich is implemented in the program-ming language C. Part (a) shows themodules of foo and their import depen-dencies. The top-level module main im-ports from a and b, which both importfrom c. foo may be represented in differ-ent ways. Some examples are given in(b), (c), and (d):

—In (b), foo is stored in the file system.Each module is represented by multi-ple files. The suffixes .h, .c, .o, and.exe denote header files, body files,compiled code, and executables, re-spectively. Dependencies and buildsteps are stored in a text file (thesystem model sys, e.g., a make file[Feldman 1979]).

—In (c), we assume a data model thatsupports typed objects and relation-ships (e.g., an EER model as used inPCTE [Oquendo et al. 1989]). As inthe file system representation, thereis still a composition tree whoseleaves correspond to single files. How-ever, dependencies are not repre-sented in a separate text file. Rather,the tree is augmented with relation-



ships reflecting include dependencies.Build dependencies are not given ex-plicitly because they can be computedautomatically from source dependen-cies and composition relationships.

—In (d), there is no longer a spanningtree, and all files making up a moduleare summarized in one object. Fur-thermore, only a single type of rela-tionship is used, which representssource dependencies between mod-

ules.1 This organization, which hasbeen realized, for example, in POEM[Lin and Reiss 1995], corresponds di-rectly to the logical structure dis-played in (a).

1 This relationship may be annotated by an at-tribute that distinguishes between include depen-dencies emanating from header and body.

Figure 1. Different representations of a software product.



3. VERSION SPACE

A version model defines the items to beversioned, the common propertiesshared by all versions of an item, andthe deltas, that is, the differences be-tween them. Furthermore, it deter-mines the way version sets are orga-nized. To this end, it introducesdimensions of evolution such as revi-sions and variants, it defines whether aversion is characterized in terms of thestate it represents or in terms of somechanges relative to some baseline, itselects a suitable representation for theversion set (e.g., version graphs), and italso provides operations for retrievingold versions and constructing new ver-sions.

The characterization of version mod-els given in this section is still incom-plete. Although the previous section de-scribed the product space withouttaking versioning into account, the cur-rent section conversely focuses on theversion space, abstracting from theproduct space. Thus we are not con-cerned with the kinds of items put un-der version control, and we also con-sider versions of a single item only.However, a version model needs to ad-dress the interplay between productspace and version space as well (Section4).

3.1 Versions, Versioned Items, and Deltas

A version v represents a state of anevolving item i. v is characterized by apair v 5 (ps, vs), where ps and vsdenote a state in the product space anda point in the version space, respec-tively. The term item covers anythingthat may be put under version control,including, for example, files and directo-ries in file-based systems, objects storedin object-oriented databases, entities,relationships, and attributes in EER da-tabases, and so on. Versioning can beapplied at any level of granularity,ranging from a software product downto text lines.

A versioned item is an item that is put

under version control. In contrast, onlyone state is maintained for an unver-sioned item; that is, changes are per-formed by overwriting. Versioning re-quires a sameness criterion; that is,there must be some way to decidewhether two versions belong to thesame item. This decision can be per-formed with the help of a unique identi-fier, for example, an OID in the case ofsoftware objects.

Within a versioned item, each versionmust be uniquely identifiable through aversion identifier (VID). Many SCM sys-tems automatically generate uniqueversion numbers and offer additionalsymbolic (user-defined) names servingas primary keys. However, a versioncan also be identified by an expression,which is the identification scheme usedby intensional versioning.

All versions of an item share commonproperties called invariants. These in-variants can be represented, for exam-ple, by unversioned attributes or rela-tionships. Which invariants are sharedby versions depends on the specific ver-sion model or the way it is customizedto a certain application. At one end ofthe spectrum, versions virtually shareonly a common OID. For example, insystems such as SCCS and RCS ver-sions of a text file may differ in arbi-trary ways. At the other end of thespectrum, versions must share semanticproperties. For example, version controlin algebraic specification [Ehrig et al.1989] enforces that all versions of amodule body realize the shared inter-face.

Versions differ with respect to specificproperties (e.g., represented by ver-sioned attributes). The difference be-tween two versions is called a delta.This term suggests that differencesshould be small compared to invariants.Delta can be defined in two ways (Fig-ure 2):

—a symmetric delta between two ver-sions v1 and v2 consists of propertiesspecific to both v1 and v2 (v1 \ v2 and



v2 \ v1, respectively, where \ denotesset difference); or

—a directed delta, also called a change,is a sequence of (elementary) changeoperations op1. . .opm which, whenapplied to one version v1, yields an-other version v2 (note the correspon-dence to transaction logs in databases).

In practice, deltas are not necessarilysmall. In the worst case, the commonpart of v1 and v2 may even be empty. Infact, items may undergo major changes,and the common properties may becomesmaller and smaller the more versionsare created. For example, it is usuallyunrealistic to assume that all versionsof module bodies realize the same inter-face (this assumption is made, e.g., inthe algebraic approach already cited[Ehrig et al. 1989] and in the Gandalfsystem [Kaiser and Habermann 1983]).On the other hand, common propertiesdo have to be asserted because other-wise it does not make sense to groupversions at all.

A way out of this dilemma is multi-level versioning; that is, a version mayhave versions themselves. For example,in Adele [Estublier 1985] a module hasmultiple versions of interfaces each ofwhich is realized by a set of body ver-sions. DAMOKLES [Dittrich et al. 1986]generalizes this idea and supports re-cursive versioning; that is, any versionmay be versioned in turn.

3.2 Extensional and Intensional Versioning

A versioned item is a container for a setV of versions. The functionality of ver-

sion control is heavily influenced by theway V is defined. Extensional versioningmeans that V is defined by enumeratingits members:

V 5 $v1,. . ., vn%.

Extensional versioning supports re-trieval of previously constructed ver-sions (which is a necessary requirementto any version model). All versions areexplicit and have been checked in oncebefore. Each version is typically identi-fied by a unique number. The user in-teracting with the SCM system re-trieves some version vi, performschanges on the retrieved version, andfinally submits the changed version as anew version vi11. To ensure safe re-trieval of previously constructed ver-sions, versions can be made immutable.In many systems, all versions are madeimmutable when they are checked intothe object base [Rochkind 1975]; in oth-ers, explicit operations are provided tofreeze mutable versions [Westfechtel1996]. Furthermore, immutability maybe enforced selectively (e.g., by distin-guishing between mutable and immuta-ble attributes [Estublier and Casallas1995]).

Intensional versioning is appliedwhen flexible automatic construction ofconsistent versions in a large versionspace needs to be supported. Instead ofenumerating its members, the versionset is defined by a predicate:

V 5 $vuc~v!%.

Figure 2. Deltas: (a) symmetric; (b) directed.



In this case, versions are implicit andmany new combinations are constructedon demand. The predicate c defines theconstraints that must be satisfied by allmembers of V. A specific version v isdescribed intensionally by its properties(e.g., the Unix version supporting theX11 window system). A version is con-structed in response to some query. Forexample, such a query may simply con-sist of a tuple of attribute values (whichmay be considered the VID of the ver-sion). In this case, a query correspondsto a (partial or total) function q thatcreates versions in V based on at-tributes ranging over the domainsA1. . .An:

q : A1 x . . . x An 3 V.

Here the term “attribute” is used in ageneral way; for example, attributesmay identify variants (e.g., an os at-tribute determining the operating sys-tem) or changes (e.g., a Boolean at-tribute Fix to indicate whether a certainbug fix should be included or omitted).

The difference between extensionaland intensional versioning may be illus-trated by comparing SCCS [Rochkind1975] and RCS [Tichy 1985] to condi-tional compilation as, for example, sup-ported with the C programming lan-guage [Kernighan and Ritchie 1978].SCCS and RCS store and reconstructversions of text files (extensional ver-sioning). The preprocessor used for con-ditional compilation constructs anysource file based on the values of pre-processor variables (intensional version-ing). All fragments of the source file areexcluded whose conditions evaluate tofalse.

From SCCS/RCS and conditional com-pilation, SCM systems have been devel-oped that differ significantly in theirversioning capabilities. On the otherhand, it must be emphasized that exten-sional and intensional versioning are byno means mutually exclusive, but can(and should) be combined into a singleSCM system.

3.3 Intents of Evolution: Revisions,Variants, and Cooperation

Versioning is performed with differentintents. A version intended to supersedeits predecessor is called a revision. Revi-sions evolve along the time dimensionand may be created for various reasons,such as fixing bugs, enhancing or ex-tending functionality, adapting tochanges in base libraries, and the like.Instead of performing modifications byoverwriting, old revisions are preservedto support maintenance of software de-livered to customers, to recover fromerroneous updates, and so on.

Versions intended to coexist arecalled variants. For example, variantsof data structures may differ with re-spect to storage consumption, run-timeefficiency, and access operations. Fur-thermore, a software product may sup-port multiple operating systems or win-dow systems.

Finally, versions may also be main-tained to support cooperation. In thiscase, multiple developers work in paral-lel on different versions. Each developeroperates in a workspace [Estublier1996] that contains the versions createdand used. Cooperation policies regulatewhen versions are exported from or im-ported into a workspace. These issuesare closely related to software processmanagement and in the following areonly discussed in passing (see also Sec-tion 7.2).

3.4 Representations of the Version Space:Version Graphs and Grids

Many SCM systems use version graphsfor representing version spaces. A ver-sion graph consists of nodes and edgescorresponding to (groups of) versionsand their relationships, respectively.Since a version graph assumes an ex-plicitly given set of versions, it is ap-plied in conjunction with extensionalversioning. Despite the limitations dis-cussed in the following, they are widelyused in practice.

Although a rich variety of version



graphs is conceivable, the mainstreamof SCM systems is based on a smallnumber of graph types.

In the simplest case (one-level organi-zation), a version graph consists of a setof versions connected by relationships ofa single type, called successor relation-ships. A version graph of this type pri-marily represents the evolution historyof a versioned item. “v2 is a successor ofv1” means that v2 has been derived fromv1, for example, by modifying a copy ofv1.

Version graphs may have differentshapes (Figure 3). In the most restric-tive case, versions are organized into asequence of revisions. In a version tree,successors of nonleaf versions may becreated, for example, in order to main-tain old versions that have already beendelivered to a customer. In an acyclicgraph, a version may have multiple pre-decessors, for example, in order to ex-press that a bug fix in an old version ismerged with the currently developedversion.

Several SCM systems use one of thesedifferent kinds of one-level organiza-tion, for example, sequences in NSE[Adams et al. 1989] and acyclic graphsin PCTE [Oquendo et al. 1989].DAMOKLES [Dittrich et al. 1986] sup-ports user-defined structural con-straints. The structure of a versiongraph may be defined in the databaseschema as a sequence, a tree, or a di-rected acyclic graph.

In two-level organization, a versiongraph is composed of branches, each ofwhich consists of a sequence of revi-

sions. Here at least two relationshiptypes are required, called successor(within a branch) and offspring (be-tween branches) in Figure 4. This orga-nization is applied, for example, in RCS.ClearCase [Leblang 1994] goes beyondthe RCS organization by recordingmerges in the version graph. By meansof merging, changes performed on onebranch can be propagated to anotherbranch. Essentially, this results in adirected acyclic graph. However, thebranches are not joined; rather, each ofthem continues to exist.

Version graphs as presented previ-ously support management of variantsonly to a limited extent. Variants can berepresented by branches as long astheir number is small. In the case ofmultidimensional variation, this ap-proach breaks down because the num-ber of branches explodes combinatori-ally. Let us assume that each dimensionis modeled by an attribute with domainAi. Then the number of branches b isdominated by the product of the domaincardinalities:

b # uA1u. . .uAnu.

To illustrate this, let us assume thatour sample product foo varies with re-spect to the operating system (DOS,Unix, VMS), the database system (Ora-cle, Informix, dbase), and the windowsystem (X11, SunViews, Windows). Inthis case, up to 27 branches would berequired.

This problem can be solved in thefollowing ways.

Figure 3. Version graphs (one-level organization): (a) sequence; (b) tree; (c) acyclic graph.



—Version graphs may be generalized inorder to support multidimensionalvariation. In Figure 5(a), versions areorganized into clusters that are usedto construct classification hierarchies[Dittrich and Lorie 1988].

—Alternatively, versions may be ar-ranged in a grid (Figure 5b), that is,an n-dimensional space whose dimen-sions correspond to variant attributes[Sciore 1994].

Figure 5 illustrates only the variantspace, assuming that there is no evolu-tion along the time axis. Revisions canbe represented in the grid by adding atime dimension (orthogonal versionmanagement [Reichenberger 1994]). Inthe case of the version graph, one levelmay be added at the bottom and succes-sor relationships may be introduced torepresent histories.

3.5 State-Based and Change-BasedVersioning

In Section 3.1, a version has been de-fined as a state of an evolving item.Version models that focus on the statesof versioned items are called state-based. In state-based versioning, ver-sions are described in terms of revisionsand variants.

Changes provide an alternative wayof characterizing versions. In change-

based models, a version is described interms of changes applied to some base-line. To this end, changes are assignedchange identifiers (CID) and potentiallyfurther attributes to characterize thereasons and the nature of a change.Change-based versioning provides anice link to change requests: a changerequest is implemented by a (possiblycomposite) change. Thus a version maybe described in terms of the changerequests it implements.

“State- versus change-based” is or-thogonal to “extensional versus inten-sional.” State-based extensional version-ing is provided, for example, by SCCSand RCS and state-based intensionalversioning can be realized, for example,by conditional compilation: preprocessorvariables can be used to represent vari-ants, and a state may be specified bytuples of values for these variables.However, we emphasize that in generalconditional compilation can be used forboth state- and change-based versioning(the latter is done, e.g., in the COVsystem [Gulla et al. 1991]).

Change-based versioning comes intwo forms. In the case of change-basedextensional versioning, the version set isdefined explicitly by enumerating itsmembers and each version is describedby the changes relative to some base-line. Thus changes are used only for

Figure 4. Version graphs (two-level organization).



documentation. The OVUM reportabout SCM systems [Rigg et al. 1995]uses the term change package to denotethis form of change-based versioning.Several SCM systems support changepackages by annotating versions in ver-sion graphs with change identifiers(e.g., ClearCase and PCMS).

In change-based intensional version-ing, changes are combined freely to con-struct new versions as required. There-fore a change is considered a partialfunction c : V 3 V, where V denotes theset of all potential versions of someitem. A version v is constructed by ap-plying a sequence of changes c1 . . . cn toa baseline b:

v 5 c1 o . . . o cn~b! 5 cn~. . . c1~b!. . .!.

The OVUM report (and also the sur-vey by Feiler [1991a]) adopts the termi-nology coined by the Aide-de-Camp sys-tem [Software Maintenance andDevelopment Systems 1990] and callsthis form of versioning the change setmodel. Further examples of systemssupporting change-based intensional

versioning are the COV system [Gullaet al. 1991], PIE [Goldstein and Bobrow1980], DaSC [MacKay 1995], and As-gard [Micallef and Clemm 1996].

The change space (version spacestructured in terms of changes) can berepresented in different ways. The COVsystem arranges versions in an n-di-mensional grid called option space.Each change corresponds to a Booleanoption that is set to true (false) if thechange is applied (omitted). The Aide-de-Camp documentation introduces amatrix representation as shown in Fig-ure 6(a). Lines and columns correspondto versions and changes, respectively.The application of a change is indicatedby a circle at an intersection point. Forexample, v1 is constructed by applyingc1, c2, and c3 in order.

Figure 6(b) illustrates the relations tothe version graphs introduced in Fig-ures 3 and 4, respectively. The versionsshown in (a) are arranged in a graphwhose nodes and edges correspond toversions and changes, respectively. bdenotes the baseline, and intermediate

Figure 5. n-dimensional variant space: (a) version graph; (b) grid.



versions are anonymous. For example,the path from b to v1 again contains thechanges c1, c2, and c3. This versiongraph explicitly expresses all changesincluded in a certain version, and there-fore provides more information than theversion graphs shown in Figures 3 and4. In particular, it makes explicit whencertain changes were applied to multi-ple versions. For example, c4 was usedto construct both v2 and v3. In contrast,state-based versioning does not namethe changes; that is, the changes areanonymous. As a consequence, thechanges applied to a version must bededuced from the topology of the versiongraph. This may become difficult ifmerging is applied in extensive andcomplicated ways (or even impossible ifmerges are not recorded at all).

4. INTERPLAY OF PRODUCT SPACE ANDVERSION SPACE

In Section 2, the product space wasdescribed under the assumption thatonly one version of each item is main-tained. In Section 3, basic definitionsfor versioning were given without con-sidering the product space. The currentsection combines product space and ver-sion space into a versioned object base.

So far, we have considered versioningof a single item only, and we have madeno assumptions concerning the kinds of

items put under version control. Asmentioned earlier, a version modelneeds to address the interplay betweenproduct space and version space as well.In the following, we discuss those as-pects of version models that are con-cerned with this interplay. In particu-lar, we investigate which items are putunder version control, at what granular-ity versioning is applied both externallyand internally, how versions of differentitems are interrelated, what models areused for representing versioned objectbases, and how the version model maybe related to the data model.

4.1 AND/OR Graphs

AND/OR graphs [Tichy 1982a] providea general model for integrating productspace and version space. An AND/ORgraph contains two types of nodes,namely, AND nodes and OR nodes.Analogously, a distinction is made be-tween AND and OR edges, which ema-nate from AND and OR nodes, respec-tively. An unversioned product graphcan be represented by an AND/ORgraph consisting exclusively of ANDnodes/edges. Versioning of the productgraph is modeled by introducing ORnodes. Versioned objects and their ver-sions are represented by OR nodes andAND nodes, respectively.

Note that the version graph illus-

Figure 6. Change space: (a) matrix representation; (b) version graph with explicit changes.



trated in Figure 5(a) can be regarded asan AND/OR graph as well: version clus-ters and versions correspond to ORnodes and AND nodes, respectively.However, in the following we are notconcerned with the capabilities ofAND/OR graphs to model the versionspace of a single object. Rather, we areinterested in the relations between ver-sions of different objects, abstracting forthe moment from the ways in whichtheir version spaces are structured.Therefore in the following a versionedobject is simply represented by an ORnode whose outgoing edges point to itsversions.

AND edges are used to represent bothcomposition and dependency relation-ships. A relationship is bound to a spe-cific version if the corresponding ANDedge ends at an AND node; otherwise itis called generic. A configuration is rep-resented by a subgraph spanned by allnodes that are transitively reachablefrom the root node of the configuration.If all AND edges belonging to this sub-graph are bound, the configuration iscalled bound as well; otherwise it iscalled generic. Furthermore, we maydistinguish between partially and to-tally generic configurations. In the firstcase, there are both bound and genericAND edges; in the latter case, all ANDedges are generic. A bound configura-tion can be constructed from a genericconfiguration by eliminating the ORnodes, that is, by selecting one succes-sor of each OR node reached duringtraversal from the root node.

In the following, we return to theexamples of product graphs in Figure 1and compare several approaches to ver-sioning the product graph. Figure 7shows AND/OR graphs that are allbased on Figure 1(b).2 In Figure 7(a)only atomic software objects are ver-sioned. foo represents a generic configu-ration. In Figure 7(b) foo is versioned as

well. Each version of foo corresponds toa bound configuration. In Figure 7(c)references to components are generic,and the versions of foo therefore repre-sent generic configurations.

Using this figure, we may classify ver-sion models according to the selectionorder during the configuration process:

—Product first (Figure 7(a)) means thatthe product structure is selected first;subsequently, versions of componentsare selected. This approach is fol-lowed, for example, by SCCS andRCS. It suffers from the restrictionthat structural versioning cannot beexpressed (the product structure isthe same for all configurations).

—Version first (Figure 7(b)) inverts thisapproach: the product version is se-lected first and uniquely determinesthe component versions. Differentproduct versions may be structured indifferent ways. For example, a versionof component c is contained only infoo.1 (version 1 of product foo). PCTE[Oquendo et al. 1989] is an example ofan SCM system using this organiza-tion.

—Intertwined (Figure 7(c)) means thatAND and OR selections are performedin alternating order. The intertwinedorganization is used, for example, byClearCase [Leblang 1994], which ver-sions both files and directories. Again,this selection scheme supports struc-tural versioning.

Thus, “version first” and “inter-twined” both take into account that dif-ferent versions of an object may varywith respect to their relationships to(versions of) other objects. This meansthat in addition to objects, relationshipsare versioned as well.

So far, we have applied versioningonly to the product graph organizationshown in Figure 1(b). In Figure 8, thealternatives “intertwined” and “versionfirst” are illustrated for the productgraph of Figure 1(d) (To save space,“product first” has been omitted). Incontrast to the previous figure, AND

2 Module versions are identified by numbers. Forthe sake of simplicity, each module version isrepresented by a single node (e.g., no distinctionbetween header files and bodies).



edges represent dependencies instead ofcomposition relationships. Intertwinedselection is performed, for example, inAdele [Estublier 1985], whereas “ver-sion first” is realized, for example, inPOEM [Lin and Reiss 1995].

To illustrate the differences betweenFigures 8(a) and (b), let us assume thata bug is fixed in module c that does notaffect its interface. A new version c.2 iscreated that is to be included in the newrelease of our sample product foo.3 In(a), a new configuration is constructedin which c.2 is selected instead of c.1.However, in (b) new versions of all mod-ules above c have to be created (ver-

sions 29 of a, b, and main, respectively).This effect is called version prolifera-tion. Note that version proliferationneed not involve physical copying (e.g.,multiple versions may share the samesource file through pointers). However,this does not solve the problem at thelogical level (the user is confronted witha combinatorially exploding number ofversions). To get rid of version prolifer-ation at the logical level, we have todistinguish between versions of modulesand versions of configurations (in (b),the versions of main play both rolessimultaneously).

4.2 Granularity of Versioning

In the previous examples we consideredversioning only at the coarse-grained

3 The current release (the starting point for thebug fix) is represented in Figure 8 by filled nodes.

Figure 7. Different kinds of AND/OR graphs and selection orders (I): (a) product first; (b) version first;(c) intertwined.



level. This means that we have appliedversioning to product graphs as intro-duced in Section 2. As explained earlier,product graphs detail the product struc-ture only down to the level of softwareobjects such as interfaces and bodies ofmodules; the fine-grained contents arerepresented as long attributes.

However, in Section 3 we introducedthe term “item” in a more general wayto denote anything that can be ver-sioned, including entities, relationships,and attributes. In particular, versioningcan be applied at any level of granular-ity.

To clarify this issue, let us furtherelaborate the notion of granularity.First, version granularity refers to thesize of a version and second, delta gran-ularity refers to the size of those unitsin terms of which deltas are recorded: inRCS version and delta granularity areat the level of text files and text lines,respectively. In this case, the deltagranularity is much finer than the ver-sion granularity.

With respect to version granularity,we need to distinguish further betweenexternal versioning and internal ver-

sioning. An SCM system provides anexternal interface to the versioned ob-ject base that offers versioned items aswell as identification and selection ofversions to its users. At the externalinterface, software objects are the itemssubject to version control. The internalgranularity may be much smaller (seethe following).

External versioning may be applied indifferent ways to the composition hier-archy of software objects. Componentversioning means that only atomic ob-jects are put under version control.Each object has its own version space,modeled, for example, by a versiongraph. Total versioning applies to alllevels of the composition hierarchy.Product versioning differs from totalversioning by arranging versions of allobjects in a uniform, global versionspace.

This classification is illustrated inFigure 9, where externally versioned ob-jects are surrounded by boxes. TheAND/OR graph in Figure 9(a) was takenfrom Figure 7(a), and the graphs shownin (b) and (c) were both copied fromFigure 7(b). Note that the topology of an

Figure 8. Different kinds of AND/OR graphs and selection orders (II): (a) intertwined; (b) version first.



AND/OR graph shows which objects areversioned, but externally and internallyversioned objects are not distinguished.Thus a given AND/OR graph can beaccessed in different ways, dependingon the version model presented to theuser. In particular, in the case of prod-uct versioning the user may select ver-sions of nonroot objects, but this is donein the version space attached to thewhole product.

Component Versioning. In compo-nent versioning, the product structureis selected first. Typically, versions ofcomponents are organized into versiongraphs (see, e.g., RCS [Tichy 1985]). Aconfiguration is constructed by assem-bling versions of components; this iscalled composition model in Feiler[1991a]. Note that the granularity ofcomposition is an “atomic” software ob-ject (rather than fine-grained units suchas statements or text lines).

Frequently, the version graphs of dif-ferent components are related onlyweakly to each other. To illustrate this,Figure 10 shows a sample configurationwhose components are located at differ-ent places in the respective versiongraphs.4 The selection problem can bealleviated by tagging all components ofsome consistent configuration with the

same symbolic name (or more generallythrough configuration rules referring torevisions and variants). Thus a configu-ration is represented implicitly throughan attribute value rather than as afirst-class entity.

Total Versioning. Total versioninggeneralizes component versioning inthat all objects are versioned ratherthan only the leaves of the compositionhierarchy. In contrast to component ver-sioning, versions of composite objectsare represented explicitly as entities;atomic and composite objects are ver-sioned uniformly. Whereas componentversioning implies that the productstructure is selected first, total version-ing may be combined with both the “ver-sion first” and the “intertwined” selec-tion order and can therefore expressstructural versioning. For example,PCTE [Oquendo et al. 1989] supportsextensional versioning of composite ob-jects (“version first”). In contrast, inClearCase [Leblang 1994] AND/OR se-lections are intertwined: a version of adirectory references a set of versionedfiles (or directories) rather than specificversions of these. A single-version viewon the versioned file system is providedthrough dynamically evaluated configu-ration rules (intensional versioningwith dynamic binding).

Product Versioning. Product ver-sioning differs from total versioning byarranging versions of all objects in a

4 AND nodes representing versions are placed in-side the OR node representing the versioned com-ponent. Furthermore, the AND/OR graph is aug-mented with successor relationships.

Figure 9. External versioning: (a) component versioning; (b) total versioning.



uniform, global version space. It may beregarded as a layer that simplifies se-lection against a versioned object base.Product versioning sets up a transpar-ent single-version view that hides inter-nally maintained versions of objects andrelationships from users and tools.Product space and version space areorthogonal to each other: a given modelof the product space can be combinedwith different models of the versionspace and vice versa. The integration ofproduct space and version space in thestate-based SCM system VOODOO[Reichenberger 1994] is illustrated inFigure 11, where versioned objects, re-visions, and variants are organized intoorthogonal dimensions.

All change-based systems (e.g., theCOV system [Gulla et al. 1991], Aide-de-Camp [Software Maintenance andDevelopment Systems 1990], and DaSC[MacKay 1995]) support product ver-sioning to overcome the limitations ofcomponent versioning. In general, achange to a software product may affectmultiple components. Since the compo-sition model falls short of recordingthese cross-dependencies, it is difficultto incorporate a change into a productversion by selecting the respective com-ponent versions. Therefore in change-based approaches product versions aredescribed in terms of global changes.Note that combination of changes oper-ates at a finer granularity (e.g., textlines) than composition of components.

Product versioning has become moreand more popular because of its globalview on the software product. A poten-tial problem consists of lacking modu-larity of the version space. All changes,revisions, and variants are global. Forexample, if there are two implementa-tion variants of a procedure Sort (e.g.,QuickSort and HeapSort), we must intro-duce an attribute at the global level inorder to enable choices between thesevariants. An approach to structure theversion space (in the COV system) isdescribed in Munch [1996].

4.3 Deltas

To represent versions in the object base,deltas are used both at the coarse-grained and the fine-grained levels. Theselection of an appropriate delta repre-sentation is driven by different require-ments to be considered at the physicaland logical level, respectively. Storageand run-time efficiency have to beachieved at the physical level. At thelogical level, deltas are used to compareversions in such a way that the user isprovided with a high-level description ofdifferences. Furthermore, intensionalversioning relies on deltas as well. Byprocessing the deltas, a version is con-structed that must meet the require-ments stated in its intensional descrip-tion. Accordingly, we distinguish betweenphysical and logical deltas. Althoughmany SCM systems use a single delta

Figure 10. AND/OR graph augmented with successor relationships.



representation for both purposes [Munch1993], physical and logical deltas mayalso be separated (e.g., syntactic merg-ing of program modules stored as textfiles [Buffenbarger 1995]).

The distinction between directed andsymmetric deltas, as illustrated in Fig-ure 2, can be transferred directly to theimplementation level. Using directeddeltas [Tichy 1982b], a version is con-structed by applying a sequence ofchanges to some base version. In thecase of embedded deltas, all versions arestored in an overlapping manner so thatcommon fragments are shared. Eithereach version points to its fragments[Fraser and Myers 1986], or the frag-ments are decorated with control expres-sions for determining the versions inwhich they are visible (interleaved del-tas [Rochkind 1975; Leblang andMcLean 1985]).

Please note that the internal deltarepresentation is orthogonal to the ex-ternal version model. For example, in-terleaved deltas may be used to realizeboth extensional and intensional ver-sioning as well as both state- andchange-based versioning. In the follow-ing, the different types of delta repre-sentations are discussed in turn.

RCS [Tichy 1985], which is based ondirected deltas, reconstructs versions oftext files from the most recent versionon the main trunk of the version graph

by applying backward deltas on themain trunk and forward deltas on thebranches. RCS deltas are fine-grained,whereas change-based SCM systemssuch as PIE [Goldstein and Bobrow1980] and DaSC [MacKay 1995] employdirected deltas at both the coarse-grained and the fine-grained level. Inboth systems, the modifications per-formed in a change are stored in a layer.A product version is composed of a se-quence of layers that are stacked on topof each other. (For further details, seethe description of PIE in Section 6, inparticular, Figure 21.)

Since versions are stored in an over-lapping manner, AND/OR graphs can beclassified as embedded deltas. As de-scribed so far, versions can be combinedfreely to derive bound configurationsfrom some generic configuration. This“combinability” can be constrained bycontrol expressions (configuration rules)stating, for instance, that a certain ver-sion can be selected only when configur-ing a Unix variant.

Adding control expressions results inan interleaved delta scheme that is real-ized in SCCS [Rochkind 1975] andDSEE [Leblang and McLean 1985]among others. Note that both systemsimplement a version model similar toRCS, which is based on directed deltas.In SCCS and DSEE, fragments of text

Figure 11. Product versioning.



lines are tagged with the set of versionsin which they are included.

SCCS and DSEE support extensionalversioning (of text files) but conditionalcompilation employs interleaved deltasfor intensional versioning. For example,Figure 12(a) illustrates conditional com-pilation in a source file varying withrespect to the operating system. Figure12(b) demonstrates that conditionalcompilation can be applied at thecoarse-grained level as well. The figurecontains a cutout of a product descrip-tion written in the Proteus Configura-tion Language (PCL [Tryggeseth et al.1995]). The selected version of the filescomponent depends on the value of theos attribute, which refers to the operat-ing system. In contrast to conditionalcompilation (single-source versioning),different versions of this component arestored in separate files (version segrega-tion) [Mahler 1994].

Version segregation is vulnerable tothe multiple maintenance problem[Babich 1986]: a change to a commonfragment must be applied to all versionsin turn. This is even the case when thefragment is shared at the physical level(e.g., interleaved deltas in SCCS).Merge tools may reduce the multiplemaintenance problem by partly auto-mating change propagation. However,single-source versioning is a more ele-gant solution since the change needs tobe performed only once for all versions,

although it may still have to be testedin multiple versions.

On the other hand, editing of sourcefiles cluttered with control expressionsmay confuse the user. Multiversion edi-tors overcome this problem by hidingcontrol expressions (see, e.g., P-Edit[Kruskal 1984], MVPE [Sarnak et al.1988], and COV [Gulla et al. 1991]). Aread filter selects a single version, re-moving all control expressions; a writefilter constrains the set of versions towhich the change is applied. For exam-ple, a general change in common partsof the source file may be performed bysetting up a universal write filter andselecting some arbitrary version by theread filter (e.g., the Unix version). IfUnix is also selected for writing, thecontrol expressions of all changed partsare set up so that all changes are spe-cific to the Unix version.

4.4 Relations Between Version Model andData Model

To conclude this section, we discuss theinterplay between product space andversion space in terms of its implica-tions for database management. Whendesigning a database management sys-tem for software engineering, the de-signer must decide how to support ver-sioning. In particular, there are severalalternatives concerning the relations

Figure 12. Interleaved deltas: (a) fine-grained level; (b) coarse-grained level.



between the data model and the versionmodel.

Version Model on Top of the DataModel. In this case, version manage-ment is seen as an ordinary databaseapplication. Thus the version model isrepresented by a schema whose under-lying data model is not aware of ver-sioning. This solution has been adopted,for example, by PCTE [Oquendo et al.1989] and CoMa [Westfechtel 1996],which are based on an EER and a graphdata model, respectively. Its main ad-vantage is that the data model is keptsimple and potentially application-spe-cific extensions are avoided (a widelyaccepted uniform version model doesnot yet exist).

However, implementing version man-agement completely on top of a data-base management system has a numberof limitations. For example, there is nosupport for storing versions efficiently,the transaction manager does not takeversioning into account, and so on.Therefore several database manage-ment systems provide predefined classesfor version management (e.g., O2[GOODSTEP 1995]). In this case, thedata model is still not aware of version-ing, but components of the databasemanagement system such as storageand transaction manager are modifiedto support version management effi-ciently.

Version Model Built into the DataModel. If the data model is extendedwith versioning, applications can besupported through a data-definition

language that provides customized con-structs for defining versioned objecttypes. In addition, the query languageis modified so that queries againsta versioned database can be writtenin a convenient and natural way.DAMOKLES [Dittrich et al. 1986], EX-TRA-V [Sciore 1994], and Adele [Estub-lier and Casallas 1994] follow this ap-proach.

If the version model is defined on topof the data model, different types arerequired for versioned objects and theirversions. As argued in Estublier andCasallas [1994] and Sciore [1994], thisdistinction is awkward and complicatesboth schemata and queries. Figure 13illustrates how this problem is solved inAdele. In this example, only one objecttype is defined for a versioned interface.Adele distinguishes between commonattributes shared by all revisions, modi-fiable attributes whose values are revi-sion-specific, and immutable attributes,where each update triggers the creationof a new revision. Furthermore, the at-tribute realization is declared as ver-sioned, meaning that an interface revi-sion may have multiple realizationvariants.

Data Model on Top of the VersionModel. So far, the version model de-pends heavily on the data model, beingeither defined on top of or built into thedata model. In a few SCM systems, suchas ICE [Zeller and Snelting 1995] andCOV [Munch 1996], the version model iscompletely orthogonal to the datamodel. This may be achieved through an

Figure 13. Definition of a versioned object type.



instrumentable version engine that pro-vides a basic delta storage and configu-ration rules by means of which specificversion models may be expressed [Con-radi and Westfechtel 1997]. The versionengine is not aware of the data modeland can thus be combined with any datamodel (e.g., EER, object-oriented, orsimply files).

Both ICE and COV are based on in-terleaved deltas, but use different logicsfor control expressions. In ICE, version-ing is applied to file-based data. TheCOV system applies versioning to anEER data model. To this end, a layerthat takes care of the consistency con-straints inherent in the data model isplaced on top of the version engine (e.g.,a relationship is visible only when bothends belong to the currently selectedversion). Thus this architecture differsconsiderably from the architecture ofconventional database management sys-tems where version model and datamodel are rather entangled.

5. INTENSIONAL VERSIONING

In Section 3.2 we distinguished betweenextensional and intensional versioning.Extensional versioning is concernedwith the reconstruction of previouslycreated versions and requires versionidentification, immutability, and effi-cient storage. On the other hand, inten-sional versioning deals with the construc-tion of new versions from property-baseddescriptions. Intensional versioning isvery important for large version spaces,where a software product evolves intomany revisions and variants and manychanges have to be combined.

In order to support intensional ver-sioning, an SCM system must providefor both combinability—any version hasto be constructed on demand—and con-sistency control—a constructed versionmust meet certain constraints. The con-struction of a version may be viewed asa selection against a versioned objectbase. The selection is directed by config-uration rules, which constitute an es-sential part of a version model, and is

performed both in the product spaceand the version space. Having discussedthe interplay between product spaceand version space in Section 4, we arenow ready to elaborate on rule-basedversion construction, a topic that couldhave been addressed only partially inSection 3.

5.1 Problem: Combinability VersusConsistency Control and Manageability

Configuration rules are used to config-ure consistent versions from a versionedobject base. Rules are required to ad-dress the combinability problem. Thenumber of potential versions explodescombinatorially; only a few are actuallyconsistent or relevant. The combinabil-ity problem has to be solved in anyversion model.

For example, the (state-based) compo-sition model [Feiler 1991a] applies ex-tensional versioning at the componentlevel; that is, previously constructedcomponent versions are reused. Rule-based construction of configurationsrealizes intensional versioning at theconfiguration level; that is, new combi-nations of component versions are as-sembled into configurations. Withoutany constraints, the number of potentialconfigurations is very large. For a prod-uct consisting of m modules existing inv versions, there exist vm potential con-figurations (i.e., the number of potentialconfigurations grows polynomially in v).

On the one hand, change-based ver-sioning reduces the combinability prob-lem by grouping logically related modi-fications of multiple components. Thuswe do not have to worry about whichversions of components actually fit to-gether. However, the selection problemhas not disappeared. Rather, it hasbeen moved from the product space tothe version space [Munch 1996]. In thecase of unconstrained combination ofchanges (each change may either be ap-plied or skipped), there are 2c potentialconfigurations for c changes; that is, thenumber of potential configurationsgrows exponentially in c.



The challenge of intensional version-ing consists of providing for consistencycontrol while still supporting combin-ability. The space of all potential ver-sions is much larger than the space ofconsistent ones. The problem of consis-tency control can be addressed both inthe version space and in the productspace. In the version space, configura-tion rules are used to eliminate incon-sistent combinations; in the productspace, the knowledge about software ob-jects, their contents, and their relation-ships is enriched in order to check andensure product constraints. SCM sys-tems tend to solve the problem in theversion space because they frequentlyonly have limited knowledge of theproduct space (typically, software ob-jects are represented as text files).

Even if a sophisticated tool for con-structing a version is employed, theuser must be warned if a new version iscreated that has never before been con-figured. Although old versions can beassigned levels of “confidentiality” (e.g.,tested or released), a new version can-not be trusted blindly. Therefore theconfigured version is subject to qualityassurance (e.g., testing). Potentially,changes to the constructed version needto be performed (correction delta).

5.2 Conceptual Framework for IntensionalVersioning

Figure 14 illustrates our conceptual

framework for intensional versioning.First let us define the central notion ofconfiguration rule: a configuration ruleguides or constrains version selectionfor a certain part of a software product.Thus a configuration rule consists of aproduct part, which determines itsscope in the product space, and a ver-sion part, which performs a selection inthe version space (see Section 5.3 forfurther details).

A versioned object base combinesproduct space and version space andstores all versions of a software product,relying, for example, on interleaved del-tas. The versioned object base is aug-mented with a rule base of stored config-uration rules (e.g., control expressionsas shown in Figure 12).

A query consists of a set of submittedconfiguration rules, each composed of aproduct part and a version part. A con-figurator is a tool that constructs a ver-sion by evaluating a query against aversioned object base and a rule base.The constructed version has to satisfyboth version constraints (e.g., consistentselection of the Unix version) and prod-uct constraints (e.g., syntactic or seman-tic consistency). Configurators are dis-cussed further in Sections 5.4 and 5.5.

The configuration process is con-cerned with the binding of generic refer-ences. Often, its result is a bound con-figuration, but it may also deliver aconfiguration that is partially generic.

Figure 14. Intensional versioning.



The latter results in a multistage config-uration process.

Binding can be performed at differentpoints in time. Static binding meansthat the configurator resolves all un-bound references before any componentis accessed. To this end, the configura-tor constructs a table that maps eachcomponent name to a specific version.In dynamic binding, each reference isevaluated on demand only (e.g., when asource file is read by a compiler).

Binding may even be deferred untilruntime. In this case, a program is con-figured dynamically without stoppingits execution. A popular example is Javaapplets, which are loaded dynamicallywhen they are activated through a Webbrowser. Dynamic configuration hasbeen studied in the context of distrib-uted systems (see Kramer [1993] for anoverview). Up to now, the relations toSCM have not been investigated thor-oughly. Only recently have a few ap-proaches been proposed that apply ver-sion-selection techniques from SCM todynamic configuration [Warren andSommerville 1995; Schmerl and Marlin1995]. However, elaborating on thistopic goes beyond the scope of this arti-cle.

To sharpen the focus, we also refrainfrom discussing system building [Bori-son 1989]. Although the conceptualframework illustrated in Figure 14 canbe applied to both source and derivedobjects, the problems to be consideredare different in the following respects.

—In source version construction, wehave a selection problem in both prod-uct and version space. The selectionmust be performed so that the out-come of the configuration processobeys all configuration rules andproduct constraints. Here nondeter-minism may have to be taken intoaccount and the configurator mayhave to backtrack from wrong selec-tions.

—When constructing derived versions,we primarily have to consider the effi-ciency and accuracy of the build.

Mostly, build rules are deterministicwith respect to the result of building.Nondeterminism deals only with theorder in which build steps are exe-cuted (the build plan imposes only apartial order on the build steps).Some authors advertise the advan-tages of nondeterministic build rules(e.g., “build some sort program nomatter what algorithm and whichcompiler is used” [Rich and Solomon1991]). However in many situations itis crucial to control the details of abuild without leaving the freedom fornondeterministic choices (e.g., eventhe functional behavior of a programmay depend on whether it is compiledwith or without optimization).

Finally, Figure 14 suggests that therule base is not put under version con-trol. On the other hand, versioning ofthe rule base is desirable as well be-cause the configuration rules mayevolve along with the software product.In the case of our sample software prod-uct foo the set of supported operatingsystems, window systems, and databasesystems may evolve, as may the con-straints on combining these dimensionsof variation. Currently, versioning ofthe rule base is handled at best in arudimentary way, such as by storingconfiguration rules in text files that aresubject to version control. As argued inConradi and Westfechtel [1997], simpletime-stamped revisions of the rule basemay suffice to reconstruct not only oldproduct versions, but also the configura-tion rules valid at that time. Some fur-ther remarks on this topic follow inSection 7.2.

5.3 Configuration Rules

Intensional versioning is driven by con-figuration rules that are classified inthe following. First, built-in rules arehardwired into the respective SCM sys-tem and cannot be changed by the user.For example, a built-in rule may enforcethat at most one version of a softwareobject is contained in any constructed



configuration. User-defined rules aresupplied by the user (e.g., “select thelatest version before May 22nd”).

Version Parts of Configuration Rules.Configuration rules take on differentforms depending on how the versionspace is structured. Figure 15 providessome typical examples that refer to therevision, variant, and change space, re-spectively. Configuration rules arestated as logical formulas, abstractingfrom the actual syntax as implementedin different SCM systems.

In the revision-space category, config-uration rules refer to the time dimen-sion. Rule (1) selects the latest revisionby the maximal time stamp. Rule (2)refers to a revision by its number.

In the variant space, configurationrules refer to values of variant at-tributes. Rule (3) identifies a variant byspecifying operating system, windowsystem, and database system. Rule (4)expresses a constraint on the combina-tion of attribute values: the X11 windowsystem is not available under the DOSoperating system.

In the change space, Rule (5) specifiesa version in terms of the changes to beapplied. Rules (6) and (7) specify furtherrelationships that describe consistentchange combinations. Rule (6) statesthat inclusion of change c2 implies thatc1 is included as well (c2 is based onc1). Rule (7) states that changes c1, c2,and c3 are mutually exclusive (operatorV) (i.e., at most one of these changesmay be applied).

Product Parts of ConfigurationRules. So far we have discussed onlythe version parts of configuration rules.The product part describes the scope ofa configuration rule in the productspace. In Figure 16, a configuration ruleis written in the form p : v, where p andv denote product part and version part,respectively. Rule (1) applies to a singlemodule a (local rule) and selects theversion checked out by the current user.The star in Rule (2) indicates globalapplication to all modules so that thesame variant is selected throughout thewhole product. The product part of Rule(3) denotes all modules reachable fromb by a reflective and transitive closureover relationships of type DependsOn;that is, the rule applies to b and to allmodules on which b depends transi-tively.

Ordering of Configuration Rules.Configuration rules can be ordered instrictness classes. A constraint is a man-datory rule that must be satisfied. Anyviolation of a constraint indicates aninconsistency. For example, Rule (1) inFigure 17 ensures that all selected ver-sions belong to a given variant. A pref-erence is an optional rule that is appliedonly when it can be satisfied. For exam-ple, Rule (2) states that a checked-outversion is selected provided it is avail-able. Finally, a default is also an op-tional rule, but is weaker than a prefer-ence: a default rule is applied only whenno unique selection could be performedotherwise. For example, Rule (3) selectsthe most recent version as the default.

Strictness classes determine the orderin which configuration rules are evalu-ated (constraints 3 preferences 3 de-faults). In addition, rules may be givenpriorities. Rules with high priorities areconsidered before low-priority rules. Apriority may be assigned explicitly or

Figure 15. Version parts of configuration rules.

Figure 16. Scoping of configuration rules.



may be defined implicitly by textual or-dering. Priorities may be combined withstrictness classes such as by assigningpriorities to preferences [Lavency andVanhoedenaghe 1988]. However theycan also be used without strictnessclasses. For example, in ClearCase[Leblang 1994] rules are evaluated ac-cording to their textual order until a(unique) match is found.

Finally, we may distinguish betweenstored and submitted configurationrules. The rules given in Figure 17would typically be submitted in a queryin order to specify properties requestedby the user. Rule (4) in Figure 15 is anexample of a stored configuration ruleexpressing a constraint that must befulfilled by all configured versions.

Relations Between Version Graphsand Configuration Rules. To concludethis section, we discuss briefly how ver-sion graphs and configuration rules arerelated in different SCM systems:

—Configuration rules on top of versiongraphs. This is the classical solution,called composition model in Feiler[1991a]. Version graphs are main-tained for components (extensionalversioning); configurations are con-structed by selecting component ver-sions with the help of configurationrules (intensional versioning). Thecomposition model is realized, for ex-ample, in DSEE [Leblang andMcLean 1985] and ClearCase [Leb-lang 1994].

—Version graphs on top of configurationrules. This inverted approach is fol-lowed by a few research prototypessuch as ICE [Zeller 1995] and COV[Munch 1996]. Both systems rely on a

flexible and powerful base layer pro-viding for delta storage (interleaveddeltas) and configuration rules. Anydesired version model may be realizedon top of configuration rules. In thecase of version graphs, revisionchains and branches may be ex-pressed by implication and mutual ex-clusion, respectively (see Rules (6)and (7) in Figure 15).

5.4 Configurators: Tools for EvaluatingConfiguration Rules

A configurator constructs a version byevaluating configuration rules against aversioned object base. Construction canbe performed in different computationalframeworks. In a functional framework,intensional versioning is modeled by ap-plying a (potentially partial) function q(query) to its arguments a1 . . . an; thatis, a version v is constructed by evaluat-ing the expression q(a1, . . . , an). Thisapproach assumes that version con-struction delivers a deterministic result(i.e., version selection is unique).

In a rule-based framework, versionconstruction is modeled as the evalua-tion of a query against a deductive data-base [Ramamohanarao and Harland1994; Ramakrishnan and Ullman 1995].The deductive database consists of aversioned object base and a rule basecontaining stored configuration rules.Since a query may not specify the ver-sion to be constructed in a unique way,a rule-based configurator has to copewith nondeterminism. Ambiguous choicescan be resolved either automatically orinteractively. In any case, the configu-rator needs to explore a search space ofpotential solutions. To this end, it mayuse different search strategies such as“depth-first” or “breadth-first.”

Configurators may be classified notonly with respect to the computationalparadigm (functional, rule-based) butalso with respect to the underlying ver-sion model (state- or change-based).This results in four combinations, asdescribed in the following.

Figure 17. Strictness classes.



State-Based Functional Configura-tors. A state-based functional configu-rator operates on a versioned objectbase typically represented by inter-leaved deltas. Conditional compilationin C [Kernighan and Ritchie 1978] andconfiguration construction at thecoarse-grained level in PCL [Tryggesethet al. 1995] may be cited as examples.5

The versioned object base is usually tra-versed in a “context-free” manner (e.g.,sequences of text lines in conditionalcompilation and trees of components inPCL). Configuration rules take the formof control expressions as shown, for ex-ample, in Figure 12. The configurator issupplied with a tuple of attribute values(a1, . . . , an) and constructs some ver-sion v. Control expressions are evalu-ated against this tuple to select therelevant components of v. When appliedto a composite object co, expressionsmay also be used to transform (a1, . . . ,an) into a new tuple (a91, . . . , a9m),which is then employed recursively toconfigure co. This means that attributevalues are transformed and propagatedthrough the composition hierarchy. Inthis way, it is possible to enforce certainconstraints (e.g., selection of the samevariant throughout the whole configura-tion process). However rule-based con-figurators are in general more powerfulin enforcing constraints or detecting in-consistencies.

State- and Rule-Based Configura-tors. A state- and rule-based configu-rator supports nondeterminism throughan appropriate search strategy (e.g.,depth-first search with backtracking). Ittypically operates on some AND/ORgraph that is traversed along “context-sensitive” relationships (e.g., dependen-cies between modules in Adele [Estub-lier 1985]; see also Figure 8). For eachOR node reached in the course of theconfiguration process, a successor is se-lected with the help of configuration

rules. As version selections are per-formed, constraints are added that nar-row down further choices. For example,if version uniqueness is required, wemay not select a different successoreach time a certain OR node is visited.Variant selection serves as another ex-ample: after having selected a certainvariant of an operating system, we mustensure that this selection is performedconsistently for all further nodesreached in the course of the configura-tion process. If this turns out to beimpossible, the configurator has tobacktrack from the wrong selection.

A simple example is given in Figure18(a) which shows an AND/OR graphwhose AND nodes (versions) are anno-tated with configuration rules.6 Foreach version, a triple of attribute valuesdenotes the variants to which it belongs;p stands for any value. a depends on thewindow system, b on the database sys-tem, and c on the file system; main canbe used with any variant. Figure 18(b)shows a query that leaves all attributevalues unspecified. Below, a sampletrace of the configuration process isgiven. After selection of a.1, the os at-tribute is bound to Unix. Thus the Unixversion of c is selected. However, selec-tion of b fails and triggers backtracking.

Change-Based Functional Configura-tors. A change-based functional con-figurator is supplied with a sequence ofchanges. Internally, the object base maybe stored using either interleaved ordirected deltas (e.g., Aide-de-Camp[Software Maintenance and Develop-ment Systems 1990] and PIE [Goldsteinand Bobrow 1980], respectively). Con-ceptually, the changes are applied inorder to some baseline. Inconsistenciesare detected when a change operationfails, for example, insertion of a textline at an undefined location.

Change- and Rule-based Configura-tors. A change- and rule-based con-

5 Please recall that conditional compilation can beused for change-based versioning as well (see Sec-tion 3.5).

6 Note that only variants are considered in thisexample (no revisions).



figurator differs from its functionalcounterpart by considering stored con-figuration rules constraining changecombinations. Configuration rules canbe used to detect inconsistent changecombinations; furthermore, they can beemployed in a constructive manner tocomplete a partial specification. This isdone, for example, in the COV system[Munch 1996]. Consider the mutual ex-clusion rule (7) in Figure 15. If the userinsists on applying both c1 and c2, theconfigurator reports an inconsistency.Alternatively, the configurator may au-tomatically disable change c2 (and c3)after c1 has been selected.

5.5 Merge Tools

So far, we have distinguished betweenstate-based and change-based configu-rators. Although state- and change-based SCM systems may differ consider-ably at first glance, the borderline is in

fact rather fuzzy.7 In particular, state-based SCM systems often offer mergetools [Buffenbarger 1995] to combineversions/changes. Although mostly usedin state-based systems, they have beenapplied in change-based systems aswell.

Merge tools combine versions orchanges. They may be classified as fol-lows (Figure 19).

—Raw merging simply applies a changein a different context. For example, inFigure 19(a) change c2 was originallyperformed independently of change c1and is later combined with c1 to pro-duce version v4. Raw merging is sup-ported by SCCS [Rochkind 1975]among others. It was later general-ized in change-based SCM systemssuch as Aide-de-Camp [SoftwareMaintenance and Development Sys-

7 This was already demonstrated in the discussionof the relationships between version graphs andchange-based versioning (Section 3; see Figure 6).

Figure 18. Rule-based construction of a configuration: (a) AND/OR graph with configuration rules; (b)construction of a configuration.



tems 1990] and the COV system[Munch et al. 1993].

—A two-way merge tool (Figure 19(b))compares two alternative versions a1and a2 and merges them into a singleversion m. To this end, it displays thedifferences to the user who has toselect the appropriate alternative. Atwo-way merge tool can merely detectdifferences, and cannot resolve themautomatically.

—To reduce the number of decisions tobe performed by the user, a three-waymerge tool (Figure 19(c)) consults acommon baseline b if a difference isdetected. If a change has been appliedin only one version, this change isincorporated automatically. Other-wise, a conflict is detected that can beresolved either manually or automat-ically (the latter is not recommended).Notably, the change-based systemAide-de-Camp offers a three-waymerge tool in addition to raw merg-ing.

In comparing raw merging and three-way merging, we have to distinguishbetween inconsistencies and conflicts:

—In raw merging, a change c is appliedin a different context. A change is asequence of change operations, sayop1 . . . opm. If any opi fails (e.g.,because it is applied to a nonexistentobject), there is an inconsistency.

—In addition to inconsistencies, three-way merging can detect conflicts, thatis contradictory changes. Three-waymerging attempts to combine two se-

quences of change operations. A con-flict arises if two operations do notcommute (e.g., contradictory changesto the name of a procedure). In rawmerging, one change wins and theother is overridden.

Merge tools can be characterized bythe semantic level at which merging isperformed (i.e., their knowledge aboutthe product space):

—Textual merging is applied to textfiles [Adams et al. 1986]. Almost allcommercial SCM systems support tex-tual merging [Rigg et al. 1995]. Al-though we can expect only an arbi-trary text file as the result of themerge (and, e.g., not a legal C pro-gram) and only physical conflicts canbe detected, textual merging seems toyield good results in practice [Leblang1994]. In particular, it works wellwhen small, local changes to largewell-structured programs are com-bined and changes have been coordi-nated beforehand so that semanticconflicts are unlikely to occur.

—Syntactic merging exploits the con-text-free (or even context-sensitive)syntax of the versions to be merged.Therefore, it can guarantee a syntac-tically correct result and can performmore intelligent merge decisions.However, syntactic merging has beenrealized only in a few research proto-types [Buffenbarger 1995; Westfech-tel 1991].

Figure 19. Types of merging: (a) raw merging; (b) two-way merging; (c) three-way merging.



—Semantic merging takes the seman-tics of programs into account [Berzins1994, 1995; Binkley et al. 1995; Hor-witz et al. 1989]. Semantic mergetools perform sophisticated analysesin order to detect conflicts betweenchanges. However, it is a hard prob-lem to come up with a definition ofsemantic conflict that is neither toostrong nor too weak (and is decid-able). Furthermore, the merge algo-rithms developed so far are applicableonly to simple programming lan-guages (not C or C11). For thesereasons, semantic merge tools havenot (yet?) made their way into prac-tice.

Finally, operation-based merging[Lippe and van Oosterom 1992] comesup with a general algorithm that makesno assumptions about the productspace. The algorithm takes two se-quences of change operations and com-bines them into a single sequence, de-tecting both inconsistencies and conflicts.However, the application of this algo-rithm is complex because a huge searchspace of potential merged operation se-quences must be considered. Because ofits generality, the merge tool cannotrely on any hints as to which operationshould be appended next and whereconflicting operations are positioned inthe input sequences.

Note that merge tools try to detectconflicts in the product space (by detect-ing noncommuting operations). Alterna-tively, conflict detection can be per-formed in the version space to someextent. This approach is followed inthe COV system [Munch 1996], whereconfiguration rules are used to con-strain change combinations. Conflictingmerges can be excluded by constraintsof the form c1 V c2 (mutual exclusion ofc1 and c2). Once such a constraint hasbeen set up, attempts to combine c1 andc2 can be detected as erroneous beforeperforming the actual merge. However,before c1 and c2 are known to conflict, itis frequently necessary to combine them(by raw merging) and test the result.

6. VERSION MODELS IN SCM SYSTEMS

After having characterized version mod-els in general, we now take a look atconcrete systems. We draw a picture ofthe SCM landscape by describing thecontributions of a representative selec-tion of influential SCM systems. Thesedescriptions are based primarily on thepublished scientific literature. Althoughthe following survey includes commer-cial systems in addition to research pro-totypes, we do not provide a comprehen-sive overview of SCM systems availablein the commercial marketplace (seeRigg et al. [1995] for such an overview).Furthermore, our main goal is to illus-trate different version models ratherthan to evaluate the functionalities pro-vided by SCM systems.

The survey focuses on the core issuesof versioning discussed in Sections 2through 5. Further topics such as sys-tem building, cooperation support,workspace management, and distribu-tion are mentioned briefly at best. As aconsequence, influential systems whosemain merits lie in these fields are notincluded. For example, Make [Feldman1979], Odin [Clemm 1995], and CAPITL[Adams and Solomon 1995] are con-cerned with system building, and NSE[Adams et al. 1989] has contributed toworkspace management (hierarchy ofworkspaces) and cooperation support(optimistic concurrency control).

6.1 Overview

We have selected more than 20 SCMsystems that vary widely in their under-lying version models. The evolutiongraph in Figure 20 illustrates the evolu-tion of SCM since the early ’70s. Eachnode corresponds to a specific systemand briefly describes its original contri-bution(s). Incoming edges express themost important influences of previoussystems.

Before delving into the details, let usmake some global remarks.

—Initially, SCM was supported throughisolated tools covering specific aspects



(e.g., SCCS [Rochkind 1975] for ver-sioning of source objects). Later on,integrated systems were developedthat combined the functionalities ofindividual tools into a coherent envi-ronment (e.g., DSEE [Leblang andMcLean 1985] or ClearCase [Leblang1994]).

—The pioneers addressed many prob-lems in an ad hoc manner. Subse-quent systems addressed topics suchas intensional versioning in a moresystematic and general way (e.g.,compare version selection by check-out options to full-fledged logic-basedapproaches such as ICE [Zeller1995]).

—Many fundamental ideas are ratherold. For example, although change-based versioning has been attractingsignificant attention only recently,the idea can be traced back at least tothe PIE system (change-based ver-sioning of Smalltalk programs [Gold-stein and Bobrow 1980]), which wasalready developed in the late ’70s.

—Although early systems/tools were im-plemented on top of the file system,

more recent systems increasingly usedatabase technology. This is demon-strated by the Adele system, for ex-ample, which evolved from a file-based system with an ad hoc hard-wired data model [Estublier 1985]into an active object-oriented data-base system supporting historical,logical, and cooperative versioning(revisions, variants, and workspaces,respectively) [Estublier and Casallas1994].

The evolution graph is traversed inchronological order in Section 6.3. In-stead of reading all system descriptionssequentially, the reader may focus onspecific systems. Furthermore, theedges of the evolution graph may serveas “hypertext links.”

To ease orientation, we have clusteredSCM systems into families such as “ver-sion graphs,” “conditional compilation,”“change-based versioning,” and “pro-gramming-in-the-large” (systems forconfiguring modular programs). Thesefamilies should be viewed just as exam-ples. They are neither disjoint (e.g., As-gard supports change-based versioning

Figure 20. Evolution graph of SCM systems.



on top of version graphs), nor do theycover all SCM systems.

6.2 Taxonomy-Based Classification

In this section, we classify SCM systemsaccording to a taxonomy derived fromSections 2 through 5. This taxonomyprovides a much more detailed and sys-tematic classification than the catego-ries introduced in the previous section.Furthermore, we claim that this classi-fication is orthogonal. Indeed, an impor-tant contribution of this article is todistinguish among different aspectsthat used to be mingled together.

For example, according to our defini-tion, change-based versioning just meansthat versions are described in terms ofchanges relative to some baseline. Onthe other hand, the term has other con-notations, resulting from the models ac-tually realized in change-based systems:

—Intensional versioning: as explainedin Section 3.5, change-based version-ing is not necessarily intensional (seethe discussion of change packages).The converse is also not true (see,e.g., the classical composition model,which is state-based).

—Product versioning: although allchange-based systems happen to sup-port global changes, there is no inher-ent reason why change-based version-ing could not be applied at thecomponent level. Conversely, thereare state-based systems (e.g., VOO-DOO [Reichenberger 1994]) thatmaintain versions at the productlevel.

SCM systems are classified in TablesI and II. These tables may be crossrefer-enced while reading the system descrip-tions in the next section. For each sys-tem, there is a corresponding row in thetable. The columns are organized in athree-level hierarchy. The first level de-fines categories (“general,” “productspace,” etc.). Each category serves togroup multiple features each of whichcorresponds to one dimension of theclassification scheme (“environment,”“object management,” etc.).

A feature may have values from someenumeration type (e.g., “tool-kit,” “lan-guage-based,” “structure-oriented”). Eachfeature is either single- or multivalued.In the first case, the feature is anno-tated with V and its value is indicated

Table I. Classification of SCM Systems (I)



by an x sign in the respective column. Inthe second case, we use * to annotatethe feature and a 1 for each of itsvalues.

Some features are defined only par-tially; they are not applicable to allSCM systems. For example, “selectionorder” is only meaningful for systemsbased on AND/OR graphs, and not allsystems support intensional versioning.Undefined values are indicated byhatched entries.

The tables are explained briefly in thefollowing, ordered by categories.

General. Following Dart et al.[1987], we distinguish among tool-kit,language-based, and structure-orientedenvironments; most SCM systems be-long to the first class. For object man-agement of the versioned object base, afile system or a database system may beused.

Product Space. The domain is spe-cific if the SCM system deals with spe-cific types of software objects; other-wise, it is general. All systems classifiedas specific deal with certain kinds ofprograms; however the underlying con-cepts may still be fairly general (e.g.,conditional compilation). Concerninggranularity, there are some systems

that do not deal with the fine-grainedlevel (e.g., PCTE), and a few that do notconsider the coarse-grained level (e.g.,the multiversion text editor MVPE).The latter have undefined entries forcoarse-grained relationships. All othersystems support composition relation-ships, but some of them do not takedependencies into account.

Version Space. The structure featurerefers to the way the version space ismodeled. In some cases (e.g., Gandalf),both version graphs and grids are suit-able for representing the version space.Similarly, extensional and intensionalversioning are nonexclusive (versionset). Virtually all systems support ex-tensional versioning (i.e., reconstructionof old versions, conditional compilationbeing a remarkable exception), butsome do not consider intensional ver-sioning. Finally, most SCM systems arestate- rather than change-based (ver-sion specification). A few systems pro-vide base mechanisms for both para-digms (e.g., ICE and COV).

Interplay of Product and VersionSpace. The selection order (during theconfiguration process) can be appliedonly to SCM systems based on AND/ORgraphs; in particular, it is not applied to

Table II. Classification of SCM Systems (II)



systems derived from conditional compi-lation. Note that the selection order fol-lows from the topology of AND/ORgraphs, which can be defined freely insome systems (e.g., DAMOKLES). Theexternal granularity is classified intoproduct, component, and total version-ing. Finally, the deltas feature refers tothe efficient representation of atomicsoftware objects only, that is, sharing atthe coarse-grained level is not consid-ered.

Intensional Versioning.8 With re-spect to the underlying computationalparadigm, we distinguish between func-tional configurators (e.g., conditionalcompilation) and rule-based configura-tors (e.g., DSEE or ClearCase). Classesof configuration rules refer to the strict-ness classes constraints, preferences,and defaults and are applied only if theSCM system distinguishes among dif-ferent strictness classes. Finally, allSCM systems supporting intensionalversioning (must) provide automaticconfigurators. In some systems, the con-figurator may also be used in interactivemode (e.g., ICE or Adele).

6.3 Descriptions of SCM Systems

In the following, each system is de-scribed briefly in turn. The system de-scriptions are not organized accordingto the tables presented in the previoussection (proceeding through the tableentries would be rather boring). In-stead, we focus on the specific contribu-tions of each system and its relations toother systems.

6.3.1 Conditional Compilation. Con-ditional compilation supports inten-sional versioning at the fine-grainedlevel and has become popular particu-larly in conjunction with the C program-ming language [Kernighan and Ritchie1978]. Although it was originally devel-oped for a specific domain, the underly-ing idea is fairly general. The source

text is interspersed with preprocessordirectives that refer to the values ofpreprocessor variables (see Figure 12).Thus conditional compilation uses inter-leaved deltas with visible control ex-pressions. A specific source version isconstructed by the preprocessor by fil-tering out all fragments whose controlexpressions evaluate to false. Sourceversion construction follows a functionalparadigm (no nondeterminism/back-tracking). Note that conditional compi-lation is a low-level and general mecha-nism on top of which different versionmodels can be implemented (both state-and change-based ones).

6.3.2 SCCS. SCCS [Rochkind 1975]manages versions of text files. (Binariescan also be stored, but delta storage isnot supported.) Versions are arrangedin a tree. To work on a version, it isphysically copied into a workspace (di-rectory). When the user is done with hisor her changes, the modified version ischecked back into the SCCS repository.SCCS uses interleaved deltas to storeversions in a space-efficient manner.However, in contrast to conditional com-pilation, this data structure is hidden.Thus there are interleaved deltas at twolevels when a C file with preprocessordirectives is stored under SCCS control.Although SCCS primarily supportsstate-based versioning, it does providesome low-level commands for control-ling delta applications (and even fixingdeltas) in a change-based fashion.

6.3.3 PIE. An early approach tochange-based versioning has been de-veloped at XEROX PARC [Goldsteinand Bobrow 1980]. PIE manages config-urations of Smalltalk programs that areinternally represented by graph-likedata structures. Changes are consideredglobal and may affect multiple compo-nents of a software product (productversioning). Each change is placed in alayer, and layers are aggregated intocontexts that act as search pathsthrough the layers. (DaSC [MacKay1995] is based on a similar approach.)

8 Note that merge tools (Section 5.5) were nottaken into account here.



This is illustrated in Figure 21, wherelayers contain different implementa-tions of methods m1, m2, m3 exportedby some class c.

When constructing a context, thereare two degrees of freedom: each layermay either be included or omitted; andthe included layers can be arranged inany sequential order. PIE provides rela-tionships to document conditions for thecombination of layers. For example, Adepends_on B implies that each contextcontaining A should include B as well.However PIE does not enforce any con-straints. Rather, the documented rela-tionships are merely used to warn theuser of possible inconsistencies.

6.3.4 RCS. RCS [Tichy 1982b, 1985]differs from its predecessor SCCS inseveral ways. RCS stores versions oftext files using directed deltas. The lat-est revision on the main trunk can beaccessed directly (and therefore effi-ciently), whereas all other revisions arereconstructed by applying backwardand forward deltas. Furthermore, RCSprovides a set of built-in attributes suchas version status and symbolic name. Inparticular, symbolic names may be at-tached to all components belonging to aconsistent configuration. In this way,symbolic names define threads throughthe version graphs and make recon-struction of configurations easier (seeFigure 10). However, support for inten-sional versioning is rather limited (op-tions of checkout commands referring to

version attributes); in particular, theproduct structure is selected first sothat structural versioning cannot bemodeled.

6.3.5 Gandalf. The Gandalf project[Habermann and Notkin 1986] was ded-icated to the generation of structure-oriented software development environ-ments based on abstract syntax trees.Gandalf C is an environment instancethat supports C at the programming-in-the-small level. Programming-in-the-large and version control are handled bythe SVCE subsystem [Kaiser andHabermann 1983], which is based onthe Intercol module interconnection lan-guage [Tichy 1979]. Each module has aunique and immutable interface and po-tentially multiple realization variants,each of which evolves into a sequence ofrevisions. Thus revisions and variantsare separated rather than intermixed(SCCS, RCS). A realization of an inter-face can be provided either by writing Ccode, or can be composed of other mod-ules that jointly provide the resourceslisted in the export interface (composi-tions). Gandalf enforces syntactic con-sistency of all interfaces and realiza-tions deposited into the public database.Therefore it can guarantee syntacticconsistency of all constructed configura-tions.

Gandalf supports intensional con-struction of source configurationsthrough a configurator that performsintertwined AND/OR selections. The

Figure 21. Layers and contexts in PIE.



configurator is driven by simple config-uration rules that are classified intoconstraints, preferences, and defaults.Constraints and preferences are at-tached to imports or compositions andselect specific variants/revisions. If noselection rules are given, the standardvariant/revision is selected by default.

6.3.6 DSEE. DSEE [Leblang andMcLean 1985; Leblang and Chase 1984;Leblang et al. 1988] integrates func-tions that were previously provided in-dependently by tools such as Make andSCCS/RCS. Furthermore, DSEE sup-ports rule-based construction of sourceconfigurations and improves systembuilding by maintaining a cache of de-rived objects, using more accurate dif-ference predicates than Make and par-allelizing builds over a network ofworkstations.

Source code versions are arranged inversion graphs as shown in Figure 4. Aconfiguration is specified by a systemmodel and a thread through the versiongraphs of components (Figure 22). Thesystem model describes a software sys-tem in terms of source objects and theirrelationships; furthermore, it also con-tains build rules. Versions are not refer-enced in the system model. Rather, theyare selected by configuration rules inthe configuration thread. Rules are or-dered sequentially according to theirpriorities. The DSEE configurator se-

lects the product structure first,9 whichis described in the system model, andadds version bindings, resulting in abound configuration thread that is usedfor system building.

6.3.7 P-Edit/MVPE. P-Edit [Kruskal1984] and its successor MVPE [Sarnaket al. 1988] support simultaneous edit-ing of multiple versions of a text file. Atext file is composed of fragments (se-quences of words). As in conditionalcompilation, control expressions areused to determine the visibilities offragments. Unlike conditional compila-tion, P-Edit and MVPE hide these con-trol expressions when the text file isdisplayed. Furthermore, control expres-sions are maintained automatically. Awrite filter (edit set) controls which ver-sions will be affected by a change, aread filter (view) selects a single versionto be displayed to the user. The versionspace is modeled as a grid.

In Figure 23, the table on the left-hand side lists all versions determinedby the attributes os, ws, and db. A viewcorresponds to a single row of the table,and an edit set is specified in a query-by-example style with the help of regu-lar expressions (e.g., the edit set in Fig-

9 However, it should be noted that the systemmodel itself is version-controlled: thus, a versionof the system model is selected in an initial stepnot shown in Figure 22.

Figure 22. DSEE.



ure 23 denotes all Unix versions). Whendisplaying a view, the editor highlightsfragments belonging to all versions inthe edit set (a change should be con-fined to these fragments).

6.3.8 Cedar. The Cedar environment[Teitelman 1984] supports program-ming in Cedar, a modular language de-veloped at XEROX PARC. Modules ofCedar programs contain generic refer-ences to other modules. Notably, a cli-ent module may use multiple realiza-tion versions of an imported interfacesimultaneously. The Cedar SystemModeler [Lampson and Schmidt 1983b,1983a] takes care of compiling and link-ing Cedar programs. A system model inCedar differs considerably from what isalso called system model in DSEE. Inparticular, a Cedar system model bindsgeneric references to specific versions.System models describe configurationversions in terms of immutable sourcefiles and therefore roughly correspondto bound configuration threads in DSEE(extensional versioning, “version-first”selection).

6.3.9 Adele I. In contrast to Gandalf,Adele I [Estublier 1985; Belkhatir andEstublier 1986] was developed in themid-’80s for tool-kit environments (aposteriori integration of file-basedtools). Adele generalizes Gandalf’s ap-proach to configuring modular programsin several ways. Whereas each Gandalfmodule has a unique interface, an Adelefamily may have multiple versions of itsinterface. Each interface version and itsrealization variants and revisions corre-spond to a module in Gandalf. Like

Gandalf, Adele explicitly distinguishesthree different classes of rules, namely,constraints, preferences, and defaults.However, the configuration rules aremore sophisticated and allow attribute-based version selection. Using theserules, short intensional descriptions canbe given for large and complex configu-rations.

6.3.10 DAMOKLES. DAMOKLES[Dittrich et al. 1986; Gotthard 1988] wasamong the first systems applying data-base technology to SCM. DAMOKLES isbased on an EER data model featuringcomposite objects, structural inheri-tance at both type and instance level,versioning, and database hierarchies.Composite objects may overlap at theinstance level (acyclic graphs), and theymay be defined recursively at the typelevel. Objects may carry both short andlong attributes, and the smallest granu-larity (leaves of the composition hierar-chy) may be chosen as desired (e.g.,coarse-grained objects such as modulesor fine-grained objects such as state-ments).

The version model, which is built intothe data model rather than defined ontop of it, is partly influenced by SCCS/RCS. Versions of one object are ar-ranged in a version graph, which maybe defined as a sequence, tree, or DAGin the database schema (see also Figure3). Any object type may be defined asversioned (i.e., total versioning of ob-jects at all levels of the compositionhierarchy). Versions may even have ver-sions themselves (recursive versioning).Any structure of an AND/OR graph may

Figure 23. MVPE.



be represented (product first, versionfirst, intertwined). A version inheritsfrom its generic object all attributes andcomponents (delegation).

6.3.11 PCTE. PCTE [Wakeman andJowett 1993] is a standard for openrepositories that provides an interfacefor implementing software engineeringtools. PCTE is based on a data modelcombining concepts from the EER modeland the UNIX file system. Each objectmay have at most one long attribute forwhich UNIX-like file operations are pro-vided. Links between objects are classi-fied into predefined categories, includ-ing composition links for representingcomposite objects.

PCTE offers basic versioning facili-ties [Oquendo et al. 1989]. UnlikeDAMOKLES, the version model is de-fined on top of the data model. Versionsof composite objects represent boundconfigurations (“version-first” selection).A new version is created by recursivelycopying the whole composition hierar-chy and establishing successor relation-ships between all components. Incomingand outgoing links are copied selectively(depending on link categories and cardi-nalities).

6.3.12 Shape. Shape [Lampen andMahler 1988; Mahler and Lampen 1988]is an SCM system that combines ideasdrawn from Make, DSEE, and RCS. Anattributed file system stores versionedfiles using directed deltas [Obst 1987].A Shape file consists of both versionselection rules and build rules androughly corresponds to a Make file plusa DSEE configuration thread. Derivedobjects are stored in a cache.

The original contribution of Shapelies in its integrated variant manage-ment [Mahler 1994]. Variant attributesare used in version selection rules. Fur-thermore, a set of bindings is attachedto each variant. Each binding associatesthe name of an attribute with a value.Bindings control in which order directo-ries are searched for source objects(variant segregation), which set of files

is passed to a compiler or linker (struc-tural variation), which options arepassed to a preprocessor (single-sourcevariation, conditional compilation), andwhich flags are passed to a compiler orlinker (derivation variations). In thisway, Shape integrates a blend of heter-ogeneous mechanisms previously han-dled separately from each other.

6.3.13 Aide-de-Camp. Aide-de-Camp[Cronk 1992; Software Maintenanceand Development Systems 1990] de-scribes versions of products in terms ofchange sets relative to a baseline. Achange set describes logically related,global changes that may affect multiplefiles. The finest grain of change is a textline. In contrast to layers in PIE,change sets are totally ordered accord-ing to their creation times. If change setc1 was created before c2, c1 will beapplied before c2 when both change setsare included in some product version. Inthe case of overlaps, c2 overrides thechanges in c1.

Each change set may be viewed as aswitch that can be turned either on oroff (see Figure 6). Aide-de-Camp detectsinconsistencies when reconstructing aproduct version from a baseline and asequence of change sets (e.g., modifica-tions to nonexisting text lines). Further-more, Aide-de-Camp provides a three-way merge tool for conflict detection.Unlike PIE, Aide-de-Camp does notsupport relationships that can be usedto detect inconsistent combinations ofchange sets.

6.3.14 COV. COV [Lie et al. 1989;Munch et al. 1993] denotes the versionmodel underlying the SCM subsystem ofthe EPOS software engineering environ-ment [Conradi et al. 1994]. EPOS isbased on an EER data model, wherefiles are represented by entities withlong attributes. A versioned databaseconsists of fragments corresponding, forexample, to groups of attributes or se-quences of text lines. Similarly to condi-tional compilation, each fragment is an-notated with a control expression called



visibility. Visibilities refer to globalBoolean options that constitute an n-dimensional version grid. Like MVPE,COV distinguishes between read andwrite filters, called ambition and choice,respectively. A choice is a complete setof option bindings (single version). Anambition contains a subset of the optionbindings of the choice and correspondsto some region of the version space. Theambition defines the versions to be af-fected by a change, and the choice deter-mines the version presented to the user.

COV stands for change-oriented ver-sioning, which suggests a specific inter-pretation of options: each option corre-sponds to a global change that can beeither included or omitted when config-uring a product version. In fact, bothstate- and change-based version modelscan be expressed with options [Conradiand Westfechtel 1997]. For example,version graphs may be represented withthe help of configuration rules [Gulla etal. 1991] that constrain delta applica-tion (e.g., implication for revision chainsand mutual exclusion for branches). Inparticular, these configuration rulesdistinguish COV from change-basedsystems, such as Aide-de-Camp or PIE,which provide little support for exclud-ing inconsistent change combinations[Conradi and Westfechtel 1996].

In COV, configuration rules are notonly used passively for detecting incon-sistent selections. In Munch [1996], aversion-selection tool is presented thatactively supports the user in setting upconsistent ambitions and choices by au-tomatically deducing option bindingsfrom configuration rules.

6.3.15 SIO. SIO [Bernard et al.1987; Lavency and Vanhoedenaghe1988] extends relational database tech-nology with deductive rules for versionselection. In SIO, a software productconsists of a set of modules each ofwhich is represented by a relation. Eachtuple of a relation corresponds to a sin-gle version characterized by a set ofattributes used for version selection.

Configurations are described in an

SQL-like manner. Configuration rulesin queries are classified into constraintsand preferences, the latter of which canbe ordered sequentially. Preferences actas filters that are applied only if theresulting set of versions is not empty.

In addition, the rule base containsconstraints specified by compatibilityrules. A compatibility rule is an asser-tion in a restricted first-order predicatecalculus. The conditions under whichtwo versions from different modules arecompatible are stated in terms of ver-sion attributes. Due to the restrictedform of constraints, SIO can efficientlycheck for contradictions between them.

6.3.16 Inscape. Inscape [Perry 1989]goes beyond Gandalf and Adele in ad-dressing semantic rather than syntacticconsistency. Operations exported by amodule are annotated with Hoare-likepre- and postconditions. The Inscape en-vironment assists the user in construct-ing semantically consistent programs invarious ways (inference of pre- andpostconditions from the implementationof an operation, detection of unsatisfiedpreconditions at call sites of operations,etc.).

Version control [Perry 1987] is per-formed at a semantic level and ad-dresses substitutability of operation ver-sions. To this end, Inscape defines (andchecks) various compatibility predicates(between versions v1 and v2) that en-sure either global or local substitutabil-ity. In the global case, v1 can be substi-tuted for v2 without having to inspectthe call sites. In contrast, local substi-tutability refers to specific call sites.

6.3.17 POEM. POEM [Lin and Reiss1995, 1996] is an environment for pro-gramming in C/C11 that strives to sim-plify SCM at the user interface. To thisend, SCM is provided in terms of mod-ules; that is, SCM matches the logicalabstractions made by programmers. Allcomponents of a module (includingsource code, object code, and documen-tation) are aggregated into a single ob-ject called a software unit. Software



units are connected by relationshipsthat represent dependencies betweensource objects (see Figure 1(d)).

For each software unit, a set of opera-tions is provided for editing, building,and version control. Versions of onesoftware unit are arranged in a versiontree. A version of a software unituniquely determines all versions ofunits on which it depends (“version-first” selection, see Figure 8(b)).

6.3.18 CoMa. CoMa [Westfechtel1994, 1996] manages configurations ofengineering design documents and hasbeen applied to both software engineer-ing and mechanical engineering. TheCoMa model integrates composition hi-erarchies, dependencies, and versionsinto a coherent framework based on asmall set of concepts. Configurationsare versioned objects whose componentsare connected by dependencies. Versiongraphs are maintained for both docu-ments and configurations.

CoMa is based on attributed graphs.The underlying model was defined by aprogrammed graph rewriting systemusing the PROGRES specification lan-guage [Schurr et al. 1995]. At the imple-mentation level, the database systemGRAS [Kiesel et al. 1995] is used, whichoffers primitives for version control(graph deltas) but does not introduce aversion model (this is done on top of thedata model).

Finally, for software engineering ap-plications, a structure-oriented mergetool [Westfechtel 1991] provides forthree-way merging of versions of soft-ware documents (e.g., requirements def-initions, software architectures, moduleimplementations) that are internallyrepresented as abstract syntax graphs.The merge tool preserves context-freecorrectness and detects certain kinds ofcontext-sensitive conflicts by analyzingbindings of identifiers to their declara-tions.

6.3.19 ClearCase. ClearCase [Leb-lang 1994] differs from its predecessorDSEE in several aspects. DSEE ver-

sions only files; however, ClearCasemanages versions of directories as well.All kinds of versioned objects are uni-formly denoted as elements. The ver-sioned file system may be accessedthrough a single-version view (configu-ration thread) defined by a configura-tion description. The view is a filter thatprovides tools with the illusion of work-ing in a single-version environment (vir-tual file system).

In contrast to DSEE, generic refer-ences to elements are bound dynami-cally only when an element is accessed(there is no precomputed version map).Furthermore, in ClearCase the systemmodel is accessed in the same way asany other element (whereas in DSEE itis used for constructing a bound config-uration thread; see also Figure 22).

Configuration rules are similar tothose offered by DSEE and are used toestablish workspaces for developers andto control change propagation betweenthese workspaces. A stable work envi-ronment may be set up by static rules(referring to specific versions). Dynamicrules are used to see recent changesperformed by other developers.

To support distributed SCM, ClearCaseassigns ownerships to branches in ver-sion graphs [Allen et al. 1995]. Each siteappends revisions to its allocated branch.After having imported new revisions fromanother site, three-way merging is usedto combine local and remote changes.

6.3.20 PCL. PCL [Tryggeseth et al.1995], the configuration language devel-oped in the PROTEUS project, is influ-enced by conditional compilation andmodule interconnection languages (inparticular, SySL [Sommerville andThomson 1989]). PCL is designed tomanage different types of variants atthe coarse-grained level. Variation ofthe logical structure refers to the de-composition of a system into logicalcomponents (an example was given inpart (b) of Figure 12). Variation of thephysical structure means that a logicalcomponent may be mapped in differentways into physical components (files re-



siding in directories). Finally, variationof system building occurs when a sourceobject is compiled in different ways withdifferent compilation switches.

All kinds of variations are controlledwith a single mechanism, namely, at-tributes. In a configuration description,some of these attributes are assignedspecific values. The configuration pro-cess then proceeds top-down, resolvinglogical and physical variation by meansof attributes (functional configurator).When all physical components havebeen determined, a Make file is gener-ated as a final step.

6.3.21 VOODOO. VOODOO [Reichen-berger 1994, 1995] is a file-based SCMsystem that supports orthogonal versionmanagement. Similarly to Gandalf andAdele, revisions and variants are sepa-rated from each other rather than inter-mixed in version graphs. However,VOODOO inverts the selection orderand selects the revision first. Further-more, versioning is applied at the prod-uct level rather than the componentlevel. Through a carefully designed userinterface, VOODOO tries to make ver-sion management as simple as possible.

For a given revision, software objectsare organized hierarchically in a projecttree whose leaves represent versionedcomponents. A set of globally definedvariants is associated with each version.Based on the three-dimensional modelshown in Figure 11, VOODOO providesdifferent views on a software product.For example, when the user first selectsa product revision and then a variant, aproject tree is displayed that is purgedfrom all components not belonging tothis variant.

6.3.22 Adele II. Adele II, the currentversion of Adele [Estublier and Casallas1994, 1995; Estublier 1996], differs con-siderably from the initial version de-scribed earlier in this section. In partic-ular, the data-modeling capabilitieshave been improved and generalized.Now Adele may be viewed as an activeobject-oriented database system with

general facilities for composite objects,versioning, workspaces, and processmanagement. On top of these, dedicatedSCM tools may be built (e.g., the Adeleconfigurator described earlier).

Adele distinguishes between three or-thogonal dimensions of versioning [Es-tublier and Casallas 1995]. Historicalversioning refers to the time dimensionand introduces temporal database sup-port. A versioned object evolves linearlyalong the time axis. Attributes are di-vided into three classes: common at-tributes shared by all versions, version-specific mutable attributes, and version-specific immutable attributes (see alsoFigure 13). Updates to immutable at-tributes result in creating a new ver-sion. Logical versioning (variants) issupported through set-valued attributes(e.g., a module may have multiple real-ization variants coexisting at a giventime). Cooperative versioning is realizedwith the help of typed workspaces [Es-tublier 1996]. A workspace type definesthe types of objects and relationships itcontains, as well as propagation policiesfor exchange of versions between neigh-bors (both vertically and horizontally).

6.3.23 Asgard. Asgard [Micallef andClemm 1996], which has been realizedon top of ClearCase, provides change-based versioning on top of versiongraphs. Thus it inverts the approachfollowed by COV, where version graphsmay be introduced on top of change-based versioning by defining constraintson the combination of changes. In As-gard, these constraints are derived fromthe version graphs of components.

Each component version is taggedwith the name of the activity (Asgard’sterm for change) that created it. Aworkspace is defined by a baseline anda set of activities A, one of which isdesignated as the current activity. If aversion was created by some activitya [ A, all versions on the path from thebaseline must have been created bysome other activity a9 [ A (completeselection). Furthermore, there must bea unique maximal element (unique se-



lection). In the case of a selection error,the user must either add further activi-ties to A or apply a merge tool to resolvean ambiguity.

6.3.24 ICE. Like COV, ICE [Zellerand Snelting 1995] is derived from con-ditional compilation and represents aversioned object base as a set of frag-ments that are tagged with control ex-pressions. COV and ICE differ with re-spect to their underlying logic calculus.ICE is based on feature logic: a featurecorresponds to an attribute whose valueis defined by a feature term. For exam-ple, [ws : X11] means that the ws fea-ture has the value X11. In general, afeature term denotes a set of potentialvalues and may be composed by a widerange of operators such as unification,subsumption, negation, and the like[Zeller 1996]. Probably the most impor-tant of these is unification, which isused to compose configurations (the fea-ture terms of component versions areunified). A configuration is inconsistentif unification fails (empty intersection ofvalue sets as, e.g., in [ws : X11] u [ws :Windows]).

Feature logic may be employed as abase mechanism on top of which differ-ent version models may be realized(uniform version model). In Zeller[1995] and Zeller and Snelting [1997],feature logic is used to realize thecheckout/checkin model, the composi-tion model, the long transaction model,and the change set model as introducedby Feiler [1991a] (see also Section 7.1).

Like COV, ICE supports multiversionediting. However, there is no distinctionbetween read and write filters. Rather,ICE presents all versions to be edited tothe user, using the syntax of conditionalcompilation. To this end, feature termsare mapped onto preprocessor directives[Zeller 1996]. Partial evaluation is usedto remove all fragments whose featureterms cannot be unified with the sub-mitted query. Like ClearCase, ICE sup-ports a virtual file system to enablesmooth tool integration.

7. RELATED WORK

We have given a comprehensive descrip-tion of the current state of the art ofversion models for SCM. We have fo-cused mainly on the organization of theversion space and the flexible construc-tion of consistent configurations fromintensional specifications. Furthermore,we have described and classified a sig-nificant number of representative SCMsystems. In Section 7.1, we discuss re-lated surveys conducted earlier (1988through 1991). Subsequently, we pointout how the work presented here is re-lated to other disciplines.

7.1 Related Work on Version Models

Two overviews were presented in 1988at the first SCM workshop [Winkler1988], which has launched a (still ongo-ing) series of follow-ups.10 Tichy’s[1988] paper introduces basic notionssuch as software object, source and de-rived object, and the like, and discussesversion graphs, system building, andversion selection based on AND/ORgraphs. Furthermore, the paper at-tempts to unify the terminology in theSCM field by means of a glossary. Es-tublier [1988] complements Tichy’s pre-sentation by focusing on the construc-tion of consistent configurations. Incombination, these papers reflect thestate of the art as of 1988.

The Software Engineering Institute(SEI) has published several papers thatreview and survey the state of the art inSCM [Brown et al. 1991; Dart 1991,1992b]. Perhaps the most influential ofthese was written in 1991 by Feiler[1991a], who classified the models un-derlying SCM systems into four catego-ries corresponding to different ways inwhich a user interacts with an SCMsystem. In the checkout/checkin model,component versions are transferred in-dividually between repository and work-space. The composition model supports

10 Please see Tichy [1989], Feiler [1991b], Feld-man [1993], Estublier [1995], Sommerville [1996],and Conradi [1997].



version selection through rules and as-sists the user in selecting consistentcombinations of component versions(“product first”). In the long transactionmodel, a user connects to a long trans-action and operates on a configurationversion (“version first”). Finally, in thechange set model a configuration is de-scribed in terms of change sets each ofwhich aggregates all modifications per-formed in response to some change re-quest.

The classification proposed by Feilerhelps in understanding different para-digms underlying SCM systems. Fur-thermore, the models are evaluated bydiscussing their merits and shortcom-ings. Unfortunately, the classification isnot orthogonal. The composition modeland the checkout/checkin model are notalternatives; rather, the former is builton top of the latter. Furthermore, longtransactions can be used in combinationwith any approach to specifying a con-figuration.

In 1990, Katz [1990] surveyed versionmodels for engineering databases. Katzprimarily considers electrical engineer-ing (CAD) and only mentions a few soft-ware engineering approaches. Althoughboth domains have evolved almost inde-pendently for a long time, many paral-lels do exist [Dart 1992a]. Katz intro-duces the following concepts: organizingthe version set (histories), dynamic con-figuration mechanisms (binding of ge-neric references), hierarchical composi-tions (versions of composite objects),version-grouping mechanisms (to repre-sent variants), instances versus defini-tions (instances of component versionsmay have properties that depend on therespective contexts in configurations),change notification and propagation(when and where to propagate changes),and object sharing mechanisms (work-spaces).

In several aspects, our view of versionmodels goes beyond the work presentedby Katz. His paper focuses on ap-proaches based on version graphs andrestricted to extensional versioning atthe component level. Intensional ver-

sioning is provided only at the configu-ration level, resulting in the composi-tion model introduced by Feiler. As wehave shown, there are radically differ-ent approaches such as conditional com-pilation that are not based on versiongraphs at all. Furthermore, Katz pri-marily discusses state-based version-ing. In contrast, this article coverschange-based versioning as well andinvestigates the relations among thesecomplementary approaches. Finally, con-figuration rules and the consistencyproblems of intensional versioning arediscussed only briefly by Katz.

7.2 Related Disciplines

Version management is related to manyother disciplines of computer science. Inthe following, these relations are de-scribed briefly. A major challenge of fu-ture research consists of clarifying therelations to these disciplines.

Temporal databases [Tansel et al.1993; Snodgrass 1992] record the evolu-tion history of data such that previousstates can be retrieved in addition tothe current state. Temporal databasesfocus solely on the time dimension andcover neither variants nor change-basedversioning. Furthermore, they often dis-tinguish between valid time (time in thereal world) and transaction time (timeof recording a fact in the database). Thisdistinction is not relevant for SCM be-cause software objects do not representreal-world objects existing indepen-dently of the database.

Different approaches have been devel-oped to accommodate changes to thedatabase schema. In the case of schemaevolution, only the current version ofthe schema is valid, and all data mustbe converted (in lazy or eager mode) inorder to maintain the consistency of thedatabase. In contrast, schema version-ing [Roddick 1995] makes it possible toview the data under different versionsof the schema. In SCM systems, ver-sioning of the schema (and other meta-data such as configuration rules) israrely considered seriously. On the



other hand, schema versioning oftendoes not take the versioning of instancedata into account.

Deductive databases [Das 1992; Ra-mamohanarao and Harland 1994; Ra-makrishnan and Ullman 1995] providefor persistent storage of facts and rulesand are usually based on a Prolog-likedata model. Deductive capabilities areurgently needed for intensional version-ing. On the other hand, deductive data-bases have been employed only rarely inSCM [Zeller 1995; Bernard et al. 1987;Lavency and Vanhoedenaghe 1988].Rather, many SCM systems incorporatehome-grown deductive components thathave been developed in an ad hoc man-ner.

It has been recognized for a long timethat the ACID principle cannot betransferred from short to long transac-tions [Barghouti and Kaiser 1991; Kai-ser 1995; Feiler 1991a]. Rather, precom-mit cooperation is required in order tocoordinate long-lasting developmentand maintenance tasks. Customizablepolicies have been developed to controlcooperation. Many approaches to longtransactions do not take versioning intoaccount [Barghouti and Kaiser 1991].This is a severe restriction since ver-sions play a crucial role in cooperationcontrol [Estublier and Casallas 1995].So far, only a few SCM systems supportlong transactions [Conradi and Malm1991; Godart et al. 1995]. Many othersmerely provide workspaces and mecha-nisms for controlling change propaga-tion between them [Estublier 1996].

Software process modeling [Finkel-stein et al. 1994; Curtis et al. 1992;Rombach and Verlage 1995] is con-cerned with the definition, analysis, andenactment of models of real-world soft-ware processes. Many different para-digms have been applied to processmodeling [Conradi et al. 1991], includ-ing active databases [Estublier and Ca-sallas 1994], rules [Kaiser et al. 1988;Peuschel and Schafer 1992], nets [Deit-ers and Gruhn 1990; Bandinelli et al.1993; Jaccheri and Conradi 1993;Heimann et al. 1996], imperative pro-

gramming [Sutton et al. 1995], and hy-brids of these. In order to integrateSCM and process modeling, functionaloverlap has to be considered (e.g., be-tween build tools and rule-based processengines such as Marvel [Kaiser et al.1988]). Furthermore, the definition of“product space” must be widened andmust cover process models as well. Fi-nally, dynamic interactions betweenproduct and process need to be takeninto account (e.g., replanning of tasknets after changes to the product struc-ture [Liu and Conradi 1993]).

Tool integration [Wasserman 1990] isprovided by SCM systems throughworkspaces that hide versioning fromthe tools. Workspaces can be separatedphysically from the versioned database[Rochkind 1975], or be realized as up-datable database views (virtual work-spaces, e.g., virtual file systems [Leb-lang 1994; Fowler et al. 1994]). CurrentSCM systems focus on integration offile-based tools and offer poor supportfor integrating tools operating on data-bases (e.g., CASE tools [Wallnau 1992]).The problem of integrating heteroge-neous database systems without sacri-ficing their autonomy is addressed byfederated database systems [Sheth andLarson 1990] and data warehouses[Hammer et al. 1995]. Furthermore, dif-ferent kinds of platforms or frameworksoffer plug-in interfaces for tool integra-tion, for example, broadcast messageservers [Reiss 1990] and object requestbrokers [Soley and Kent 1995]. Futuregenerations of SCM systems need tointerface with these frameworks.

Current SCM systems are severelylimited with respect to managing depen-dencies between software objects. First,they are mainly concerned with depen-dencies between source code modulesrather than with dependencies amongany kinds of software objects producedin the software lifecycle. Second, theyare not capable of representing fine-grained dependencies, which is crucialto provide for detailed traceabilitythroughout the whole lifecycle. Theseproblems can partly be addressed by



applying the concepts of hypertext sys-tems [Conklin 1987] to the software en-gineering domain.

The emerging discipline of softwarearchitectures [Shaw and Garlan 1996]stresses the importance of a high-leveldescription of software products abovethe source code level. The software ar-chitecture acts as a central documentfor impact analysis, planning of devel-opment and maintenance activities, di-vision of labor, understanding the inter-faces between different components,and so on [Nagl 1990]. SCM may benefitfrom software architectures in someways. First, SCM systems focus primar-ily on source code and represent theproduct structure by rather low-levelsystem models that are mainly used todrive system building. Architecture-ori-ented SCM will improve the softwareprocess through a high-level product de-scription. Second, the architecture ofthe SCM system is a major researchchallenge as well. In order to design anappropriate architecture, a clear under-standing of the relations among an SCMsystem and other software components(e.g., process management systems,broadcast message servers, object re-quest brokers) needs to be developed.

8. CONCLUSION

Over the past 20 years, many ap-proaches to versioning have been devel-oped. Now we have gained a sufficientlevel of understanding to classify theseapproaches. Initial attempts to developa uniform model have been undertaken[Zeller 1995; Zeller and Snelting 1997].Furthermore, the recent evolution ofSCM systems shows that their underly-ing version models are converging to anincreasing extent. For example, change-based versioning has been realized ontop of version graphs and vice versa.

Based on the material presented inthis article, we believe that a versionmodel can be developed that integratesextensional and intensional versioning,state-based and change-based version-ing, revisions and variants, construction

of source and derived versions, as wellas workspaces and long transactionsinto a coherent framework [Conradi andWestfechtel 1997]. This framework isnot expected to provide “the” model;rather, it must be customizable to suitthe needs of a specific application.

In the future, we expect that moreand more SCM systems will be builtwith the help of database technology.Having gained a better understandingof version models, versioning can bepulled out of SCM systems and movedinto database systems. In particular, in-tensional versioning will benefit fromthe powerful facilities of an underlyingdeductive database system.

ACKNOWLEDGMENTS

Many thanks go to the EPOS team in Trondheimand to the IPSEN team in Aachen. Furthermore,we would like to acknowledge the competent andcomprehensive comments of the unknown review-ers. Finally, the references were prepared partlyusing the bibliography of Hal Render, Universityof Colorado at Boulder.

REFERENCES

ADAMS E., GRAMLICH, W., MUCHNICK, S., AND TIRF-ING, S. 1986. SunPro: Engineering a practi-cal program development environment. InProceedings of the International Workshop onAdvanced Programming Environments(Trondheim, June) R. Conradi, T. M. Didrik-sen, and D. H. Wanvik, Eds., LNCS 244,Springer-Verlag, 86–96.

ADAMS, E. W., HONDA, M., AND MILLER, T. C.1989. Object management in a CASE envi-ronment. In Proceedings of the Eleventh Inter-national Conference on Software Engineering(Pittsburgh, PA, May), IEEE Computer Soci-ety Press, Los Alamitos, CA, 154–163.

ADAMS, P. AND SOLOMON, M. 1995. An overviewof the CAPITL software development environ-ment. In Software Configuration Manage-ment: Selected Papers SCM-4 and SCM-5 (Se-attle, WA, April), J. Estublier, Ed., LNCS1005, Springer-Verlag, 1–34.

ALLEN, L., FERNANDEZ, G., KANE, K., LEBLANG, D.,MINARD, D., AND POSNER, J. 1995. ClearCaseMultiSite: Supporting geographically-distrib-uted software development. In Software Con-figuration Management: Selected PapersSCM-4 and SCM-5, (Seattle, WA, April), J.Estublier, Ed., LNCS 1005, Springer-Verlag,194–214.



BABICH, W. A. 1986. Software ConfigurationManagement. Addison-Wesley, Reading, MA.

BANDINELLI, S. C., FUGGETTA, A., AND GHEZZI,C. 1993. Software process model evolutionin the SPADE environment. Trans. Softw.Eng. 19, 12 (Dec.), 1128–1144.

BARGHOUTI, N. S. AND KAISER, G. E. 1991. Con-currency control in advanced database appli-cations. ACM Comput. Surv. 23, 3 (Sept.),269–317.

BELKHATIR, N., AND ESTUBLIER, J. 1986. Experi-ence with a data base of programs. In Pro-ceedings of the ACM SIGSOFT/SIGPLANSoftware Engineering Symposium on Practi-cal Software Development Environments,(Palo Alto, CA, Dec.) ACM SIGPLAN Not. 22,1, 84–91.

BERNARD, Y., LACROIX, M., LAVENCY, P., AND VAN-HOEDENAGHE, M. 1987. Configuration man-agement in an open environment. In Proceed-ings of the 1st European Software EngineeringConference (Straßburg, Sept.), G. Goos and J.Hartmanis, Eds., LNCS 289, Springer-Verlag,35–43.

BERSOFF, E. H., HENDERSON, V. D., AND SIEGEL,S. G. 1980. Software Configuration Man-agement: An Investment in Product Integrity.Prentice-Hall, Englewood Cliffs, NJ.

BERZINS, V. 1994. Software merge: Semanticsof combining changes to programs. ACMTrans. Program. Lang. Syst. 16, 6 (Nov.),1875–1903.

BERZINS, V., ED. 1995. Software Merging andSlicing. IEEE Computer Society Press, LosAlamitos, CA.

BINKLEY, D., HORWITZ, S., AND REPS, T. 1995.Program integration for languages with pro-cedure calls. ACM Trans. Softw. Eng. Meth-odol. 4, 1 (Jan.), 3–35.

BORISON, E. A. 1989. Program changes and thecost of selective recompilation. Tech. Rep.CMU-CS-89-205 (July), Department of Com-puter Science, Carnegie Mellon University,Pittsburgh, PA.

BROWN, A., DART, S., FEILER, P., AND WALLNAU, K.1991. The state of automated configurationmanagement. Tech. Rep. ATR92 (Sept.), Soft-ware Engineering Institute, Carnegie-MellonUniversity, Pittsburgh, PA.

BUFFENBARGER, J. 1995. Syntactic softwaremerging. In Software Configuration Manage-ment: Selected Papers SCM-4 and SCM-5 (Se-attle, WA, April), J. Estublier, Ed., LCNS1005, Springer-Verlag, 153–172.

CLEMM, G. 1995. The Odin system. In SoftwareConfiguration Management: Selected PapersSCM-4 and SCM-5 (Seattle, WA, April), J.Estublier, Ed., LNCS 1005, Springer-Verlag,241–262.

CONKLIN, J. 1987. Hypertext: An introduction

and survey. IEEE Comput. 20, 9 (Sept.), 17–41.

CONRADI, R. ED. 1997. Software ConfigurationManagement: ICSE’97 SCM-7 Workshop (Bos-ton, MA, May), LNCS 1235, Springer-Verlag.

CONRADI, R., ET AL. 1994. EPOS: Object-ori-ented and cooperative process modelling. InSoftware Process Modelling and Technology,Advanced Software Development Series. A.Finkelstein, J. Kramer, and B. Nuseibeh,Eds., Research Studies Press (John Wiley),Chichester, UK, 33–70.

CONRADI, R. AND MALM, C. 1991. Cooperatingtransactions and workspaces in EPOS: Designand preliminary implementation. In Proceed-ings of the Third International Conference onAdvanced Information Systems Engineering(CAISE ’91) R. Andersen, J. A. Bubenko, andA. Solvberg, Eds. (Trondheim, May), LNCS498, Springer-Verlag, 375–392.

CONRADI, R., AND WESTFECHTEL, B. 1996. Con-figuring versioned software products. In Soft-ware Configuration Management: ICSE’96SCM-6 Workshop (Berlin, March), I. Sommer-ville, Ed., LNCS 1167, Springer-Verlag, 88–109.

CONRADI, R. AND WESTFECHTEL, B. 1997. To-wards a uniform version model for softwareconfiguration management. In Software Con-figuration Management: ICSE’97 SCM-7Workshop (Boston, MA, May), R. Conradi,Ed., LNCS 1235, Springer-Verlag, 1–17.

CONRADI, R., LIU, C., AND JACCHERI, M. L. 1991.Process modeling paradigms: An evaluation.In Proceedings of the Seventh InternationalSoftware Process Workshop (Yountville, CA,Oct.), IEEE Computer Society Press, LosAlamitos, CA, 51–54.

CRONK, R. D. 1992. Tributaries and deltas.BYTE 17, 1 (Jan.), 177–186.

CURTIS, B., KELLNER, M. I., AND OVER, J. 1992.Process modeling. Commun. ACM 35, 9(Sept.), 75–90.

DART, S. 1991. Concepts in configuration man-agement systems. In Proceedings of the ThirdInternational Workshop on Software Configu-ration Management (Trondheim, Norway,June), P. H. Feiler, Ed., ACM Press, NewYork, 1–18.

DART, S. A. 1992a. Parallels in computer-aideddesign frameworks and software developmentenvironments efforts. IFIP Trans. A 16, 175–189.

DART, S. A. 1992b. The past, present, and fu-ture of configuration management. Tech. Rep.CMU/SEI-92-TR-8 (July), Software Engineer-ing Institute, Carnegie-Mellon University,Pittsburgh, PA.

DART, S. A., ELLISON, R. J., FEILER, P. H., ANDHABERMANN, A. N. 1987. Software develop-ment environments. IEEE Computer 20, 11(Nov.), 18–28.



DAS, S. K. 1992. Deductive Databases andLogic Programming. Addison-Wesley, Read-ing, MA.

DEITERS, W. AND GRUHN, V. 1990. Managingsoftware processes in the environment MEL-MAC. In Proceedings of the Fourth ACM SIG-SOFT Symposium on Practical Software De-velopment Environments (Irvine, CA, Dec.),ACM SIGSOFT Softw. Eng. Not. 15, (6) R.Taylor, Ed., 193–205.

DITTRICH, K., GOTTHARD, W., AND LOCKEMANN, P.1986. DAMOKLES, a database system forsoftware engineering environments. In Pro-ceedings of the International Workshop on Ad-vanced Programming Environments (Trond-heim, June), R. Conradi, T. M. Didriksen, andD. H. Wanvik, Eds., LNCS 244, Springer-Verlag, 353–371.

DITTRICH, K. R. AND LORIE, R. A. 1988. Versionsupport for engineering database systems.IEEE Trans. Softw. Eng. 14, 4 (April), 429–437.

EHRIG, H., FEY, W., HANSEN, H., LOWE, M., ANDJACOBS, D. 1989. Algebraic software devel-opment concepts for module and configurationfamilies. In Proceedings of the Ninth Confer-ence on Foundation of Software Technologyand Theoretical Computer Science (Bangalore,Dec.), V. Madhavan, Ed., LNCS 405, Spring-er-Verlag, 181–192.

ESTUBLIER, J. 1985. A configuration manager:The Adele data base of programs. In Proceed-ings of the Workshop on Software EngineeringEnvironments for Programming-in-the-Large(Harwichport, MA, June), 140–147.

ESTUBLIER, J. 1988. Configuration manage-ment: The notion and the tools. In Proceed-ings of the International Workshop on Soft-ware Version and Configuration Control(Grassau, Germany), J. F. H. Winkler, Ed.,Teubner Verlag, 38–61.

ESTUBLIER, J. 1996. Workspace management insoftware engineering environments. In Soft-ware Configuration Management: ICSE’96SCM-6 Workshop (Berlin, March) I. Sommer-ville, Ed., LCNS 1167, Springer-Verlag.

ESTUBLIER, J. ED. 1995. Software ConfigurationManagement: Selected Papers SCM-4 andSCM-5 (Seattle, WA, April), LNCS 1005,Springer-Verlag.

ESTUBLIER, J. AND CASALLAS, R. 1994. The Adeleconfiguration manager. In ConfigurationManagement, W. F. Tichy, Ed., Vol. 2 ofTrends in Software, Wiley, New York, 99–134.

ESTUBLIER, J. AND CASALLAS, R. 1995. Three di-mensional versioning. In Software Configura-tion Management: Selected Papers SCM-4 andSCM-5 (Seattle, WA, April), J. Estublier, Ed.,LNCS 1005, Springer-Verlag, 118–135.

FEILER, P. H. 1991a. Configuration manage-ment models in commercial environments.

Tech. Rep. CMU/SEI-91-TR-7 (March), Soft-ware Engineering Institute, Carnegie-MellonUniversity, Pittsburgh, PA.

FEILER, P. H., ED. 1991b. Proceedings of theThird International Workshop on SoftwareConfiguration Management (Trondheim, Nor-way, June), ACM Press, New York.

FELDMAN, S., ED. 1993. Proceedings of theFourth International Workshop on SoftwareConfiguration Management (Preprint) (Balti-more, MD, May).

FELDMAN, S. I. 1979. Make—A program formaintaining computer programs. Softw.Pract. Exper. 9, 4 (April), 255–265.

FINKELSTEIN, A., KRAMER, J., AND NUSEIBEH, B.,EDS. 1994. Software Process Modelling andTechnology. Advanced Software DevelopmentSeries. Research Studies Press (Wiley), Chich-ester, UK.

FOWLER, G., KORN, D., AND RAO, H. 1994. n-DFS: The multiple dimensional file system. InConfiguration Management, W. F. Tichy, Ed.,Vol. 2 of Trends in Software, Wiley, NewYork, 135–154.

FRASER, C. AND MYERS, E. 1986. An editor forrevision control. ACM Trans. Program. Lang.Syst. 9, 2 (April), 277–295.

GODART, C., CANALS, G., CHAROY, F., AND MOLLI,P. 1995. About some relationships betweenconfiguration management, software process,and cooperative work: The COO environment.In Software Configuration Management: Se-lected Papers SCM-4 and SCM-5 (Seattle,WA, April), J. Estublier, Ed., LNCS 1005,Springer-Verlag, 173–178.

GOLDSTEIN, I. P. AND BOBROW, D. G. 1980. Alayered approach to software design. Tech.Rep. CSL-80-5, XEROX PARC, Palo Alto, CA.

GOODSTEP 1995. The GOODSTEP Project—Final Report. GOODSTEP ESPRIT Project6115.

GOTTHARD, W. 1988. Datenbanksysteme furSoftware-Produktionsumgebungen. IFB 193,Springer-Verlag, Berlin.

GULLA, B., KARLSSON, E.-A., AND YEH, D. 1991.Change-oriented version descriptions inEPOS. Softw. Eng. J. 6, 6 (Nov.), 378–386.

HABERMANN, N. AND NOTKIN, D. 1986. Gandalf:Software development environments. IEEETrans. Softw. Eng. 12, 12 (Dec.), 1117–1127.

HAMMER, J., GARCIA-MOLINA, H., WIDOM, J., LABIO,W., AND ZHUGE, Y. 1995. The Stanford datawarehousing project. Data Eng. Bull. 18, 2,41–48.

HEIMANN, P., JOERIS, G., KRAPP, C.-A., AND WEST-FECHTEL, B. 1996. DYNAMITE: Dynamictask nets for software process management.In Proceedings of the Eighteenth InternationalConference on Software Engineering (Berlin,March), IEEE Computer Society Press, LosAlamitos, CA, 331–341.



HORWITZ, S., PRINS, J., AND REPS, T. 1989. Inte-grating non-interfering versions of programs.ACM Trans. Program. Lang. Syst. 11, 3(July), 345–387.

HUMPHREY, W. S. 1989. Managing the SoftwareProcess. SEI Series in Software Engineering,Addison-Wesley, Reading, MA.

IEEE 1983. IEEE Standard for Software Con-figuration Management Plans: ANSI/IEEEStd 828-1983. IEEE, New York.

IEEE 1988. IEEE Guide to Software Configu-ration Management: ANSI/IEEE Std 1042-1987. IEEE, New York.

JACCHERI, M. L. AND CONRADI, R. 1993. Tech-niques for process model evolution in EPOS.IEEE Trans. Softw. Eng. 19, 12 (Dec.), 1145–1156.

KAISER, G., FEILER, P., AND POPOVICH, S. 1988.Intelligent assistance for software develop-ment and maintenance. IEEE Softw. 5, 3(May), 40–49.

KAISER, G. E. 1995. Cooperative transactionsfor multiuser environments. In Modern Data-base Systems (Reading, MA), W. Kim, Ed.,Addison Wesley, 409–433.

KAISER, G. E. AND HABERMANN, A. N. 1983. Anenvironment for system version control. InDigest of Papers of Spring CompCon ’83,IEEE Computer Society Press, Los Alamitos,CA, 415–420.

KATZ, R. H. 1990. Toward a unified frameworkfor version modeling in engineering data-bases. ACM Comput. Surv. 22, 4 (Dec.), 375–408.

KERNIGHAN, B. W. AND RITCHIE, D. M. 1978. TheC Programming Language. Prentice-Hall,Englewood Cliffs, NJ.

KIESEL, N., SCHURR, A., AND WESTFECHTEL, B.1995. GRAS, a graph-oriented software engi-neering database system. Inf. Syst. 20, 1(Jan.), 21–51.

KIM, W., ED. 1995. Modern Database Systems.Addison-Wesley, Reading, MA.

KRAMER, J. 1993. Special issue on configurabledistributed systems. Softw. Eng. J. 8, 2(March), 51–52.

KRUSKAL, V. 1984. Managing multi-version pro-grams with an editor. IBM J. Res. Dev. 28, 1,74–81.

LAMPEN, A., AND MAHLER, A. 1988. Shape—Asoftware configuration management tool. InProceedings of the International Workshop onSoftware Version and Configuration Control(Grassau, Germany), J. F. H. Winkler, Ed.,Teubner Verlag, 228–243.

LAMPSON, B. W. AND SCHMIDT, E. E. 1983a. Or-ganizing software in a distributed environ-ment. In ACM Symposium on ProgrammingLanguage Issues in Software Systems, ACMSIGPLAN Not. 18, 6 (June), 1–13.

LAMPSON, B. W. AND SCHMIDT, E. E. 1983b.

Practical use of a practical polymorphic appli-cative language. In Tenth Annual ACM Sym-posium on Principles of Programming Lan-guages (Austin, TX, Jan.), ACM SIGPLANNot. 18, 1, 237–255.

LAVENCY, P. AND VANHOEDENAGHE, M. 1988.Knowledge based configuration management.In Proceedings of the 21st Annual HawaiiInternational Conference on System Sciences(Hawaii, Jan.), B. Shriver, Ed., IEEE Com-puter Society Press, Los Alamitos, CA, 83–92.

LEBLANG, D. 1994. The CM challenge: Configu-ration management that works. In Configura-tion Management, W. F. Tichy, Ed., Vol. 2 ofTrends in Software, Wiley, New York, 1–38.

LEBLANG, D. B. AND CHASE, R. P. 1984. Com-puter-aided software engineering in a distrib-uted workstation environment. In Proceedingsof the ACM SIGSOFT/SIGPLAN SoftwareEngineering Symposium on Practical Soft-ware Development Environments, ACM SIG-PLAN Not. 19, 5 (May), 104–112.

LEBLANG, D. B. AND MCLEAN, G. D. 1985. Con-figuration management for large-scale soft-ware development efforts. In Proceedings ofthe Workshop on Software Engineering Envi-ronments for Programming-in-the-Large (Har-wichport, MA, June), 122–127.

LEBLANG, D. B., CHASE, R. P., JR., AND SPILKE,H. 1988. Increasing productivity with aparallel configuration manager. In Proceed-ings of the International Workshop on Soft-ware Version and Configuration Control(Grassau, Germany), J. F. H. Winkler, Ed.,Teubner Verlag, 21–37.

LIE, A., CONRADI, R., DIDRIKSEN, T., KARLSSON, E.,HALLSTEINSEN, S. O., AND HOLAGER, P. 1989.Change oriented versioning. In Proceedings ofthe Second European Software EngineeringConference (Coventry, UK, Sept.), C. Ghezziand J. A. McDermid, Eds., LNCS 387, Spring-er-Verlag, 191–202.

LIN, Y.-J. AND REISS, S. P. 1995. Configurationmanagement in terms of modules. In SoftwareConfiguration Management: Selected PapersSCM-4 and SCM-5 (Seattle, WA, April), J.Estublier, Ed., LNCS 1005, Springer-Verlag,101–117.

LIN, Y.-J. AND REISS, S. P. 1996. Configurationmanagement with logical structures. In Pro-ceedings of the Eighteenth International Con-ference on Software Engineering (Berlin,March), IEEE Computer Society Press, LosAlamitos, CA, 298–307.

LIPPE, E., AND VAN OOSTEROM, N. 1992. Opera-tion-based merging. In Proceedings of ACMSIGSOFT ’92: Fifth Symposium on SoftwareDevelopment Environments (SDE5), (Tyson’sCorner, VA, Dec.) ACM SIGSOFT Softw. Eng.Not. 17 5, 78–87.

LIU, C., AND CONRADI, R. 1993. Automatic re-planning of task networks for supporting pro-



cess model evolution in EPOS. In Proceedingsof the European Software Engineering Confer-ence ’93 (Garmisch-Partenkirchen, Germany,Sept.), I. Sommerville and M. Paul, Eds.,Springer-Verlag, 434–450.

MACKAY, S. A. 1995. The state-of-the-art inconcurrent, distributed configuration manage-ment. In Software Configuration Manage-ment: Selected Papers SCM-4 and SCM-5 (Se-attle, WA, April), J. Estublier, Ed., LNCS1005, Springer-Verlag, 180–194.

MAHLER, A. 1994. Variants: Keeping things to-gether and telling them apart. In Configura-tion Management, W. F. Tichy, Ed., Vol. 2 ofTrends in Software, Wiley, New York, 73–98.

MAHLER, A. AND LAMPEN, A. 1988. An inte-grated toolset for engineering software config-urations. In Proceedings of the ACM SIG-SOFT/SIGPLAN Software EngineeringSymposium on Practical Software Develop-ment Environments (Boston, MA, Nov.), ACMSoftw. Eng. Not. 13, 5, 191–200.

MARZULLO, K. AND WIEBE, D. 1986. Jasmine: Asoftware system modelling facility. In Pro-ceedings of the ACM SIGSOFT/SIGPLANSoftware Engineering Symposium on Practi-cal Software Development Environments (PaloAlto, CA, Dec.), ACM SIGPLAN Not. 22, 1,121–130.

MICALLEF, J., AND CLEMM, G. 1996. The Asgardsystem: Activity-based configuration manage-ment. In Software Configuration Manage-ment: ICSE’96 SCM-6 Workshop (Berlin,March), I. Sommerville, Ed., LNCS 1167,Springer-Verlag, 175–186.

MUNCH, B. 1996. HiCOV: Managing the versionspace. In Software Configuration Manage-ment: ICSE’96 SCM-6 Workshop (Berlin,March), I. Sommerville, Ed., LNCS 1167,Springer-Verlag, 110–126.

MUNCH, B. P. 1993. Versioning in a softwareengineering database—the change orientedway. Ph.D. Thesis, NTNU Trondheim, Nor-way.

MUNCH, B. P., LARSEN, J.-O., GULLA, B., CONRADI,R., AND KARLSSON, E.-A. 1993. Uniform ver-sioning: The change-oriented model. In Pro-ceedings of the Fourth International Workshopon Software Configuration Management (Bal-timore, MD, May), S. Feldman, Ed., (Preprint)188–196.

NAGL, M. 1990. Softwaretechnik: MethodischesProgrammieren-im-Großen. Springer-Verlag,Berlin.

NAGL, M. ED. 1996. Building Tightly-Inte-grated Software Development Environments:The IPSEN Approach. LNCS 1170, Springer-Verlag, Berlin.

OBST, W. 1987. Delta technique and string-to-string correction. In Proceedings of the FirstEuropean Software Engineering Conference(Straßburg, Sept., 1987), J. Goos and J. Hart-

manis, Eds., LNCS 289, Springer-Verlag, 64–68.

OQUENDO, F., BERRADO, K., GALLO, F., MINOT, R.,AND THOMAS, I. 1989. Version managementin the PACT integrated software engineeringenvironment. In Proceedings of the SecondEuropean Software Engineering Conference,(Coventry, UK, Sept.), C. Ghezzi and J. A.McDermid, Eds., LNCS 387, Springer-Verlag,222–242.

PAULK, M. C., WEBER, C. V., CURTIS, B., AND CHRIS-SIS, M. B. 1997. The Capability MaturityModel—Guidelines for Improving the Soft-ware Process. Addison-Wesley, Reading, MA.

PERRY, D. 1989. The Inscape environment. InProceedings of the Eleventh InternationalConference on Software Engineering (Pitts-burgh, PA, May), IEEE Computer SocietyPress, Los Alamitos, CA, 2–12.

PERRY, D. E. 1987. Version control in the In-scape environment. In Proceedings of theNinth International Conference on SoftwareEngineering (Monterey, CA, March), IEEEComputer Society Press, Los Alamitos, CA,142–149.

PEUSCHEL, B., AND SCHAFER, W. 1992. Conceptsand implementation of a rule-based processengine. In Proceedings of the Fourteenth Inter-national Conference on Software Engineering(Melbourne, Australia, May), IEEE ComputerSociety Press, Los Alamitos, CA, 262–279.

PRIETO-DIAZ, R., AND NEIGHBORS, J. 1986. Mod-ule interconnection languages. J. Syst. Softw.6, 4 (Nov.), 307–334.

RAMAKRISHNAN, R., AND ULLMAN, J. D. 1995. Asurvey of deductive database systems. J.Logic Program. 23, 2 (May), 125–149.

RAMAMOHANARAO, K., AND HARLAND, J. 1994. Anintroduction to deductive database languagesand systems. VLDB J. 3, 2 (April), 107–122.

REICHENBERGER, C. 1994. Concepts and tech-niques for software version control. Softw.Concepts Tools 15, 3 (July), 97–104.

REICHENBERGER, C. 1995. VOODOO—a tool fororthogonal version management. In SoftwareConfiguration Management: Selected PapersSCM-4 and SCM-5 (Seattle, WA, April), J.Estublier, Ed., LNCS 1005, Springer-Verlag,61–79.

REISS, S. 1990. Interacting with the FIELD en-vironment. Softw. Pract. Exper. 20, S1 (June),89–115.

RICH, A., AND SOLOMON, M. 1991. A logic-basedapproach to system modelling. In Proceedingsof the Third International Workshop on Soft-ware Configuration Management (Trondheim,Norway, June), P. H. Feiler, Ed., ACM Press,New York, 84–93.

RIGG, W., BURROWS, C., AND INGRAM, P. 1995.Configuration Management Tools. Ovum Ltd.,London.



ROCHKIND, M. J. 1975. The source code controlsystem. IEEE Trans. Softw. Eng. 1, 4 (Dec.),364–370.

RODDICK, J. F. 1995. A survey of schema ver-sioning issues for database systems. Inf.Softw. Technol. 37, 7 (July), 383–393.

ROMBACH, H. D. AND VERLAGE, M. 1995.-Directions in software process research. InAdvances in Computers, M. V. Zelkowitz, Ed.,Vol. 41, Academic Press, San Diego, 1–63.

SARNAK, N., BERNSTEIN, R., AND KRUSKAL, V.1988. Creation and maintenance of multipleversions. In Proceedings of the InternationalWorkshop on Software Version and Configura-tion Control (Grassau, Germany), J. F. H.Winkler, Ed., Teubner Verlag, 264–275.

SCHMERL, B. R., AND MARLIN, C. D. 1995. De-signing configuration management facilitiesfor dynamically bound systems. In SoftwareConfiguration Management: Selected PapersSCM-4 and SCM-5 (Seattle, WA, April), J.Estublier, Ed., LNCS 1005, Springer-Verlag,88–100.

SCHURR, A., WINTER, A., AND ZUNDORF, A. 1995.Graph grammar engineering with PROGRES.In Proceedings of the European Software En-gineering Conference (ESEC ’95) (Barcelona,Sept.), W. Schafer and P. Botella, Eds., LNCS989, Springer-Verlag, 219–234.

SCIORE, E. 1994. Version and configurationmanagement in an object-oriented datamodel. VLDB J. 3, 1 (Jan.), 77–106.

SHAW, M., AND GARLAN, D. 1996. Software Ar-chitecture—Perspectives on an Emerging Dis-cipline. Prentice-Hall, Englewood Cliffs, NJ.

SHETH, A. P. AND LARSON, J. A. 1990. Federateddatabase systems for managing distributed,heterogeneous, and autonomous databases.ACM Comput. Surv. 22, 3 (Sept.), 183–236.

SNODGRASS, R. T. 1992. Temporal databases. InTheories and Methods of Spatio-TemporalReasoning in Geographic Space (Pisa, Sept.),A. Frank, I. Campari, and U. Formentini,Eds., LNCS 639, Springer-Verlag, 22–64.

SOFTWARE MAINTENANCE AND DEVELOPMENT

SYSTEMS. 1990. Aide-de-Camp Product Over-view. Software Maintenance and Develop-ment Systems, Concord, MA.

SOLEY, R. M. AND KENT, W. 1995. The OMGobject model. In Modern Database Systems,(Reading, MA), W. Kim, Ed., Addison-Wesley,Reading, MA, 18–41.

SOMMERVILLE, I., ED. 1996. Software Configura-tion Management: ICSE’96 SCM-6 Workshop(Berlin, March) LNCS 1167, Springer-Verlag.

SOMMERVILLE, I., AND THOMSON, R. 1989. An ap-proach to the support of software evolution.Comput. J. 32, 5 (Dec.), 386–398.

SUTTON, S. M., HEIMBIGNER, D., AND OSTERWEIL,L. J. 1995. APPL/A: A language for soft-

ware process programming. ACM Trans.Softw. Eng. Methodol. 4, 3 (July), 221–286.

TANSEL, A. U., CLIFFORD, J., GADIA, S., JAJODIA, S.,SEGEV, A., AND SNODGRASS, R. 1993. Tem-poral Databases—Theory, Design, and Imple-mentation. Benjamin/Cummings, RedwoodCity, CA.

TEITELMAN, W. 1984. A tour through Cedar. InProceedings of the Seventh International Con-ference on Software Engineering (Orlando, FL,March), IEEE Computer Society Press, LosAlamitos, CA, 181–195.

TICHY, W. F. 1979. Software development con-trol based on module interconnection. In Pro-ceedings of the IEEE Fourth InternationalConference on Software Engineering (Pitts-burgh, Sept.), IEEE Computer Society Press,Los Alamitos, CA, 29–41.

TICHY, W. F. 1982a. A data model for program-ming support environments. In Proceedings ofthe IFIP WG 8.1 Working Conference on Auto-mated Tools for Information System Designand Development (New Orleans, Jan.), North-Holland, 31–48.

TICHY, W. F. 1982b. Design, implementation,and evaluation of a revision control system. InProceedings of the Sixth International Confer-ence on Software Engineering (Tokyo, Sept.),IEEE Computer Society Press, Los Alamitos,CA, 58–67.

TICHY, W. F. 1985. RCS—A system for versioncontrol. Softw. Pract. Exper. 15, 7 (July), 637–654.

TICHY, W. F. 1988. Tools for software configura-tion management. In Proceedings of the Inter-national Workshop on Software Version andConfiguration Control (Grassau, Germany),J. F. H. Winkler, Ed., Teubner Verlag, 1–20.

TICHY, W. F., ED. 1989. Proceedings of the Sec-ond International Workshop on Software Con-figuration Management (Princeton, NJ, Nov.),ACM Softw. Eng. Not. 14, 7.

TICHY, W. F., ED. 1994. Configuration Manage-ment, Vol. 2 of Trends in Software. Wiley,New York.

TRYGGESETH, E., GULLA, B., AND CONRADI, R.1995. Modelling systems with variability us-ing the PROTEUS configuration language. InSoftware Configuration Management: SelectedPapers SCM-4 and SCM-5 (Seattle, WA,April), J. Estublier, Ed., LNCS 1005, Spring-er-Verlag, 216–240.

WAKEMAN, L., AND JOWETT, J. 1993. PCTE—TheStandard for Open Repositories. Prentice-Hall, Englewood Cliffs, NJ.

WALLNAU, K. C. 1992. Issues and techniques ofCASE integration with configuration manage-ment. Tech. Rep. CMU/SEI-92-TR-5 (March),Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, PA.



WARREN, I., AND SOMMERVILLE, I. 1995. Dy-namic configuration abstraction. In Proceed-ings of the European Software EngineeringConference (ESEC ’95) (Barcelona, Sept.), W.Schafer and P. Botella, Eds., LNCS 989,Springer-Verlag, 173–190.

WASSERMAN, A. 1990. Tool integration in soft-ware engineering environments. In Proceed-ings of the Second International Workshop onSoftware Engineering Environ. (Chinon,France, Sept.), F. Long, Ed., LNCS 467,Springer-Verlag, 137–149.

WESTFECHTEL, B. 1991. Structure-oriented merg-ing of revisions of software documents. InProceedings of the Third International Work-shop on Software Configuration Management(Trondheim, Norway, June), P. H. Feiler, Ed.,ACM Press, New York, 68–79.

WESTFECHTEL, B. 1994. Using programmedgraph rewriting for the formal specification ofa configuration management system. In Pro-ceedings WG ’94 Workshop on Graph-Theo-retic Concepts in Computer Science (Herrsch-ing, Germany, June), E. Mayr, G. Schmidt,and G. Tinhofer, Eds., LNCS 903, Springer-Verlag, 164–179.

WESTFECHTEL, B. 1996. A graph-based systemfor managing configurations of engineering

design documents. Int. J. Softw. Eng. Knowl-edge Eng. 6, 4 (Dec.), 549–583.

WINKLER, J. F. H., ED. 1988. Proceedings of theInternational Workshop on Software Versionand Configuration Control (Grassau, Germa-ny), Teubner Verlag.

ZELLER, A. 1995. A unified version model forconfiguration management. In Proceedings ofthe ACM SIGSOFT ’95 Symposium on theFoundations of Software Engineering (Wash-ington, Oct), ACM Softw. Eng. Not. 20, 4,151–160.

ZELLER, A. 1996. Smooth operations withsquare operators—the version set model inICE. In Software Configuration Management:ICSE’96 SCM-6 Workshop (Berlin, March), I.Sommerville, Ed., LNCS 1167, Springer-Ver-lag.

ZELLER, A. AND SNELTING, G. 1995. Handlingversion sets through feature logic. In Proceed-ings of the Fifth European Software Engineer-ing Conference (Barcelona, Sept.), W. Schaferand P. Botella, Eds., LNCS 989, Springer-Verlag, 191–204.

ZELLER, A., AND SNELTING, G. 1997. Unified ver-sioning through feature logic. ACM Trans.Softw. Eng. Methodol. 6, 4 (Oct.), 397–440.

Received October 1996; revised July 1997; accepted August 1997



version models for software configuration...

Documents