Context-Preserving Software Configuration Management Henrik Bærbak Christensen Department of Computer Science University of Aarhus Ny Munkegade, Bldg. 540, ˚ DK-8000 Arhus C, Denmark +45 89 42 31 88
[email protected] ABSTRACT This paper presents a model for version control and configuration management with high emphasis on the ability to recreate the relevant context for a given part of a software design structure. The approach is termed context-preserving software configuration management.
its evolution. One aspect of this gap is that often the configuration management system requires the software design structure to be restated in a special language, often denoted a system model, giving rise to synchronisation problems when the structure evolves. Another aspect is that of maintaining overview: Not only are developers required to keep track of the many files and parts of a large software structure—they also have to maintain overview of the large number of versions of all these entities. A final, important, aspect is that the entities in the software design structure seldom exist in a vacuum but are interrelated in complex ways—relations that also evolve over time. Thus we cannot understand a single pieces of our software in isolation but must view it in its proper context—i.e. understand the interplay between it and related entities. However this context and its evolution is often very hard, if not impossible, to infer directly from the system model.
The context-preserving approach provides distributed, dynamic, configuration descriptions under full version control, enhances overview of relations between versions, lessens the selection problem, and conceptually provides a version concept that can match the logical design entities closely. Presently the context-preserving approach is used in a software development environment research project, “Ragnarok” [8], as the fundamental software configuration management layer. A prototype that implements a command-line user interface to the context-preserving layer is outlined as well as results from on-going experiments in which the prototype is used in a number of real development projects.
This paper proposes an approach denoted context-preserving software configuration management. The central idea is to version control the context of software entities. The main asset of this approach is that it provides the developers with a version concept that can closely match the logical design structure created for the project without introducing a complicated configuration language. It also relieves the developers from much of the burden of remembering how the versions of different parts of the software relate to each other.
Keywords Software design structure, versioning models and version selection, software configuration management, cooperative and parallel development, experience report. INTRODUCTION Developing and maintaining large software systems is intrinsically difficult. An approved approach to design and implementation is to adopt a “divide-and-conquer” principle and dissect the full system into manageable pieces in a hierarchical structure, often denoted for instance the software architecture [12] or software design structure [21]. This structure is usually also the framework for a work-breakdown delegating responsibilities and tasks to sub-teams and individuals.
This paper first describes a model of software design structure. In the following section the context-preserving approach is defined: The notion of context is defined in terms of the software design structure, a modification concept introduced, and it is described how new versions are created. Then follows a description of how cooperative- and parallel development are handled. A prototype implementation is then briefly described followed by a preliminary experience report. Finally the work is related to other research efforts and pointers to future work given.
Software systems evolve over time: In the development phase milestones are defined and reached, in the maintenance phase errors are corrected and functionality added in new releases. Software configuration management is the discipline of controlling the evolution of complex software systems [24], and there exists numerous models and tools devoted to this task.
MODEL OF SOFTWARE STRUCTURE In order to version control the context of a software entity we need a framework by which the context can be defined. In the context-preserving approach the software design structure of a software project is viewed as a hierarchical composition of software components. A software component is defined by
However in many of these approaches there is a gap between the actual software design structure and the management of
1
four parts:
Substance: A set of logically related software entities; typically source code files, but potentially also associated documentation, test suits, management data (e.g. logged staff hours, budgets, task- and milestone definitions), etc.
Ragnarok
Component Model
Part/Whole relations: Relate individual components in a part/whole hierarchy. This relation allows the traditional “divide-and-conquer” strategy for decomposition of large systems [21]. Reference relations: Describe uses- or depends-on relations between components (that are not already accounted for by part/whole relations). For example both a graphical user interface component and an economical domain knowledge component may depend on a general purpose mathematical library component. Transformations: A set of operations that can transform substance and/or relations: Typical examples are requests to “add file”, “remove relation”, “check-in”, “compile”, “sum logged staff-hours”, etc. Thus a software component is basically an object-oriented concept. The model can easily be extended to handle classification by inheritance but this aspect has not been exploited so far. This model may be viewed as a directed graph. In figure 1 the software structure for the context-preserving layer of Ragnarok is outlined. The nodes in the graph are components, part/whole relations are shown as solid lines with the arrow head pointing to the part component, and reference relations are shown as dashed lines from a component to the one it references/depends on. The full graph for a software project is denoted the component-graph. For example you can see in figure 1 that the software component “ComponentModel” (representing a class-category i.e. a set of logically related classes [5, 6]) consists of four part components: “SoftwareComponent”, “VersionGroup”, “RCSFile”, and “SCRegister” (they represents classes). SCRegister depends on SoftwareComponent which again depends on Library and VersionGroup and so on. The component substances, i.e. the files and data associated with the components, are not shown in order to make the figure clearer. Even though software components, as defined here, are “storage containers” they serve well as logical entities like for instance classes or class categories [5, 6] in a modelling context. For instance a component may contain interfaceand implementation files of a C++ class as well as e.g. associated documentation and thereby represent the class on a modelling level.
...
Library
Version Group
RCS File
Software Component
SC Register
Figure 1: Software design structure for parts of the Ragnarok prototype. The three dots indicate other components, part of Ragnarok, that are not relevant for the present discussion. PRESERVING CONTEXT Having software components as the basic building blocks in the design structure makes it natural to consider version groups of software components. Version groups of software components are persistent objects stored in a database. This database will be denoted the component storage. As is common the space where modifications are made by developers is denoted the workspace. A distinction is made between software components, which are the entities developers change and work on in their workspace, and software-components-in-the-storage which reside in the component storage and are immutable; they can only be read or deleted once created. A software component version group is a set of software-components-in-the-storage connected by the relations “revision-of” and “variant-of” as proposed by Tichy [24]. The essential property of the context-preserving approach is the proposal that: A version of a software component specifies the relevant context in which it was created. This way a version of a component embodies the context that was present in the workspace when the version was created. What constitutes the relevant context for a component is of course a decision that must be made by designers and developers, and expressed in terms of part/whole- and reference relations. The typical situation in software development is that the interesting context for a piece of software is the libraries and modules it depends on. For example consider component SoftwareComponent in
figure 1 that represents a class “SoftwareComponent”. This class is defined by an interface file “swcomp.h” and an implementation file “swcomp.c++”. The class depends on other classes “VersionGroup”, “RCSFile”, and various procedures in “Library”, as is apparent from the reference relations in figure 1. Creating a version of SoftwareComponent will thus not only create and maintain references to new versions of the files “swcomp.h” and “swcomp.c++” but will also maintain references to the exact versions of the related components at the time of creation.
Library
Version Group
Defining Context First let us define the following relation between two components: Definition: The relation depending-on is a relation between two components. A component A is depending-on another component B if there is a path between A and B in the component graph.
Software Component
RCS File
Figure 2: Context-graph for component SoftwareComponent. Library 1.12
...
Now the context of a component can be defined in terms of its context-graph: Definition: The context-graph for a component A is a sub-graph of the component graph for which it holds that: 1.
Version Group 1.16
...
A is the root of the graph.
2. The graph contains all components Ci for which it holds that A is depending-on Ci . 3. The graph includes all edges [Ci ; Cj ] for which it holds that both Ci and Cj are in the component set defined in point 2.
Software Component
...
1.17
...
1.40
1.12
RCS File
Loosely stated the context-graph simply encompasses all components that a component in some way depends on.
Figure 3: Example of the context for version 1.40 of component SoftwareComponent.
Example In figure 2 is depicted the context-graph of component SoftwareComponent. Compared with figure 1 it can be seen that it is simply a sub-graph.
component, here VersionGroup, but the SoftwareComponent developer has no need nor wish for using a newer but maybe more unstable version.
Figure 3 shows schematically how context is stored in the component storage, here exemplified by version 1.40 of SoftwareComponent. Version groups of software components are here depicted as rounded boxes with the version graph inside; each box represents a single version of the component (software-component-in-the-storage) with older versions on the left. From the figure you can see that SoftwareComponent version 1.40 depends on RCSFile version 1.12, VersionGroup 1.16, and Library 1.12. Note that SoftwareComponent version 1.40 references an “old” version of VersionGroup. This is a quite typical situation that arises when another developer is working on a
Modification Bits and pieces of the components are constantly modified in workspace. There are two types of modifications: Definition: A component A is directly-modified if changes are made to the substance of A i.e. changes made in any file associated with A, or modifications are made in the setup of part/whole or reference relations. A component may also be modified indirectly: Definition: A component A is indirectly-modified
if a component C in the context-graph for been directly-modified.
A has
This is arguably a “pessimistic” notion of modification: Making a change in one component is also an indirect change in everything that depends on it. Well established methods of using API’s, invariants and the notion of “programming by contract” [16] on the contrary seek to allow modifying implementation with only local effects. But the pessimistic approach provides better tracking in a world where things are often less than perfect: For instance inadvertently introducing some errors in Library would surely modify the behaviour in both SoftwareComponent and RCSFile—even though nothing was changed in the substance of these components. In this approach such an indirect modification will be recorded and will help in tracing the source of errors. Also the substance of components is not limited to handle source code. Creating Versions Creating a new version of a component A means preserving its context. This is done in the following manner: 1. Calculate the context-graph G for component A. 2. Prune the context-graph G for all components that are not directly- nor indirectly-modified. 3. Enumerate all components Ci in the pruned contextgraph in depth-first order and create a new version of each Ci with a new version identification and store it with information about the versions identifications of all components that Ci is related to. To paraphrase this the version creation is propagated to all modified components in a recursive, depth-first, manner. Creating a new version of a component Ci in step 3. of course also means creating new versions of all files associated with the component. As is common the process of creating a new version of a component will be denoted checking-in while the restoring process will be denoted checking-out. Example The check-out/check-in round trip can be illustrated by the following scenario. Please refer to figure 4. Developers working on a graphical user interface for Ragnarok realise that they need to keep the visual layout under version control. As the class VersionGroup with little effort can become a generic class, it is decided that the VersionGroup component should be “promoted” to become part of the Library. Version 1.40 of SoftwareComponent (shown in the upper left part of the figure) is checked out into workspace and modi-
fied (lower part): VersionGroup is moved from being a partcomponent of ComponentModel (not shown) to become a part-component of Library instead. Then the latest version, 1.17, is checked-out and modified. The direct reference relation from SoftwareComponent to VersionGroup can be removed as VersionGroup is now in the context of SoftwareComponent indirectly through Library. Components in the workspace are marked by “[direct]” or “[indirect]” to indicate whether they are directly- or indirectly-modified. RCSFile is indirectly modified because the Library component has been changed. After it is verified that SoftwareComponent works properly in this new context, it is checked in giving rise to new versions being defined in the component storage (upper right part of figure). Motivation So what is gained by adopting a context-preserving approach? The main points are: 1. Distributed, dynamic, configuration descriptions under version control. 2. The version concept can closely reflect our logical software design. 3. The selection problem is lessened. 4. Enhanced overview of relations and differences between versions. 5. Strong emphasis on traceability. Ad. 1: The relations to other components are part of the component itself, may freely be modified, and are under version control just as the files associated with the component are. Even though components and/or files are added, removed, or moved in the design structure between two versions, the old one can be faithfully recreated in the exact same configuration as when it was created. In the example in figure 4 the versions of SoftwareComponent states their relations to other components and is explicit about the actual versions they depend upon. In contrast the often adopted approach of having a single, central, system model or configuration description has the problem that the software structure cannot be changed without changing the description of it—leading to an obvious synchronisation problem. Ad. 2: Designers group logically related software entities into collections as for instance classes, class-categories, libraries, and subsystems, because it allows them to be discussed, documented, reused, and managed as a whole. The context-preserving approach offers to treat them as a whole in a configuration management context as well. Thereby the focus is shifted from the level of individual files to the more abstract and powerful level of design entities.
Component Storage Library
Library 1.12
...
Version Group 1.16
1.17
1.18
...
Software Component ...
1.13
...
Version Group
1.40
...
... 1.41
Software Component ...
1.13
...
1.12
RCS File
RCS File [direct]
Library Check-out SoftwareComponent 1.40
Check-in SoftwareComponent [direct]
Version Group
[direct]
Software Component [indirect]
Workspace
RCS File
Figure 4: Example of a check-out/check-in round trip. This is an important conceptual point because what designers (and surely customers!) discuss and describe as “version X.X of the product/library” is here a concrete, manifest, object in the component storage. This is in sharp contrast to other approaches like ’tagging’ all files in a project or relying on a centralised system model/configuration object. In both cases there is no central object, that is that specific version of the product or library.
queried about the versions of components it is related to. This query can be propagated throughout the context-graph to give a complete description of the context for a given version. This provides overview and is direct and straight forward compared to trying to infer it from a formal description in a system model. Also we can ask it to compute a structural difference between two versions i.e. give a list of components and/or files that have changed1.
In the example in figure 4 “version 1.40 of SoftwareComponent” is a concrete object in the component storage that we can directly ask about its relations, the versions of components it depends upon, check-out, etc.
Ad. 5: It should be clear that the evolution of components is highly traceable. This aspect is essential in release situations but also of great importance for providing historical data in project evaluations in order to improve project management (see e.g. [10]).
Ad. 3: As a version of a component itself knows the versions of all related components there is no need for selection rules, tags, or separate configuration objects to ensure that context is recreated consistently. Ad. 4: A specific version of a component can directly be
1 Such a structural difference between Library version 1.12 and 1.13 would for instance tell that component VersionGroup has been added as a part component.
Library
Generic Configurations Another way of stating the context-preserving approach is that a version of a component is a baseline configuration stating the context of the component. In other words there are never generic configurations stored in the component storage. In the workspace however we sometimes need to be able to mix different versions of different components to create and test new configurations of the system. The presented approach does of course not get in the way of incorporating strong selection engines to produce configurations in workspace based on selected attributes of a component. COOPERATIVE DEVELOPMENT Typically individual developers or teams will have responsibility for certain parts of a large software project. Their effort will often proceed through a series of “intermediate” versions until eventually a “milestone” version emerge, ready to be used more widely. In the context-preserving approach cooperative development is eased because it allows developers to view and maintain the configuration structure in terms of the design parts. Consider two developers working independently on two components, say developer A on SoftwareComponent and B on RCSFile from the example in figure 4. B can develop and experiment with the implementation of RCSFile without disturbing A because A’s SoftwareComponent references the stable version 1.13 of RCSFile. When RCSFile has reached a state that B considers to be a milestone version ready to be used project-wide, A is informed. A can then simply request component VersionGroup to check-out the milestone version and be sure to get the proper context—even if RCSFile had been a complicated library or subsystem with many part-components. However there may arise a complication in this scenario. Consider that during A’s work it becomes necessary to add new functionality to Library and a new version of Library has therefore been made. Now B produces the aforementioned milestone version of RCSFile that A wants to use. However A cannot simply check-out the new version of RCSFile because this version refers to the old version of Library—thus checking-out B’s new RCSFile version would also check-out an outdated Library missing the functionality now required by SoftwareComponent. In this case A must instead “merge” the context of SoftwareComponent with the new version of RCSFile i.e. perform a “selective check-out” that does not overwrite newer versions in the context. In this example it means developer A requests component RCSFile to perform a “selective checkout” resulting in a check-out of the new version of RCSFile but the check-out operation is not propagated to the Library component because a newer version is already present in workspace.
...
...
1.18
1.13
Software Component ...
1.41
Version Group ... 1.13
RCS File
Figure 5: Deferred branching: Branches are not made in RCSFile until necessary.
PARALLEL DEVELOPMENT Few development efforts proceed in a strictly linear fashion. This fact is reflected in that most version control systems allow parallel development on a single software entity, commonly known as having branches in the version graph. Typically a branch is created in the situation where a software system has been released and further enhancements have been added and then a (serious) bug found in the original release requiring an immediate correction. This is usually handled by creating a branch from the release baseline where the fixes are made (a maintenance or bug-fix branch) while enhancements are continuously added in another branch (often denoted the main branch). How can a branch be defined in the context-preserving case? A simple approach is to require that creating a branch in the evolutionary history of a component means creating a branch in the full context. However one pragmatic objection may be raised against this approach. Say a maintenance branch is created for SoftwareComponent and the branching is propagated throughout the context. While it is likely that there will be a number of intermediate versions in the SoftwareComponent maintenance branch, there will most likely only be a single version in the branches of Library, VersionGroup, and RCSFile—namely the initial. And the substance of the versions will probably be identical to the substance of the branching point version. Therefore it is proposed to allow deferring the branching in components that are not part-components. I.e. to maintain a “simple” evolution graph for components that are expected not to change. If it turns out later that modifications are necessary in other components, the necessary branches can be made at that
Library ...
... Version Group
1.18
component depends on the types of files associated. Ordinary text (source) files can be handled by a three-way merge. Proprietary formated files (from e.g. word-processors, CAD programs, CASE tools, etc.) must be handled manually unless a suitable merge program is provided.
1.13
Software Component ... ...
1.44
... 1.15
RCS File
Figure 6: Merging is performed throughout the full context in all components that have branches.
point. This approach is denoted deferred branching, and is illustrated in figure 5. Here it has been necessary to modify RCSFile and thus when SoftwareComponent is checked in, a branch is made in RCSFile. Merging The ability of fork the development of a software component into two or more parallel efforts raises the need to reconcile them again: In the previous example it is most likely that the bugs corrected in the maintenance branch is also pertinent for the mainstream development. One way to do this is of course manually to “cut-and-paste” the error corrections from the maintenance versions into the mainstream versions but a more reliable way is to automatically reconcile the two parallel developments into a single effort, a process usually called merging. In the context-preserving approach the merging operation must be performed in the full context of a component as seen in figure 6. Just as for the check-in operation, the merge process traverses the context in a recursive, depth-first, manner. If a branch has not been made in a component in the context there is no need for merging, as is shown in the figure where Library and VersionGroup has not been modified during the lifetime of the branch. The merging of two versions of a component means merging both the lists of files and relations described by the versions as well as merging the substance i.e. the individual versions of the files. The file-list and relation-lists are merged as follows: Denoting the last version in one branch Rev 1 and the last version in the other branch Rev 2 then if a file/relation is in the lists of either Rev 1 or Rev 2 it is kept, otherwise it is removed. The merging process performed on the files in the individual
Note that the type of reconcilement described here is different from the problem of “merging” context described in the previous section. In this section the problem is to reconcile different versions of the same component whereas the previous section considered reconciling the contexts of different components. PROTOTYPE A prototype of the context-preserving software configuration management approach has been implemented as part of the Ragnarok [8] software development environment project. Ragnarok has a graphical user interface and addresses additional issues besides software configuration management but a command line user interface to the management layer has been created and it is this tool that is described here. The prototype including a tutorial and user manual is available on the WorldWideWeb [7]. Implementation A software component is in the prototype defined by a list of files (being the substance of the component), and a list of references to part components and a list of references to components referenced. Versions of individual files are handled by RCS [22, 23]: When a component checks in the RCS “ci” command is issued to all files in the file list, and the prototype stores the resulting revision numbers for the files. The present prototype adheres to the “lock-modify-unlock” policy for granting permission to modify substance of a component i.e. only a single developer can modify a component at a time. The component storage is presently implemented by storing component version information and RCS files in a traditional directory structure. The part/whole structure is usually reflected in a subdirectory structure, but this default behaviour may be overruled on a per-component basis. A workspace is defined by a work directory structure with the same subdirectory structure as in the component storage. Presently the prototype copies everything to the workspace during a check-out; an approach that clearly must be modified in order to scale up to large systems, but suffices for experiments on small- and medium-sized projects. Multiple Developers Every developer on a project creates one or more private work directories which then define private, independent, workspaces. Presently only one developer may run the prototype at a time.
User Interface The prototype accepts commands for manipulating components (adding/removing components, adding/removing files), workspace information (list files and relations, optionally recursively through all part- and/or reference relations), version information (list file- and relation versions, optionally recursively, for a given version of a component), structural differences, and of course context-preserving check-in, check-out, and “selective check-out”.
The drawbacks in the present prototype can be summarised as:
Preliminary Results The prototype is currently used in three on-going development projects while a forth has been completed.
Version graph pollution: Intermediate versions, only representing a “snapshot of state” for one developer, still shows up on the version graphs of all other developers. This can generate some confusion about “which one is the correct one to use” and lessens the overview.
In one of the on-going experiments the prototype is used by a team of three developers that are developing a control system, “ConSys” [11], for controlling storage rings, accelerators, and other large distributed equipment in experimental physics. The second on-going experiment is the continued development of the Ragnarok prototype itself. In the third experiment the focus is on release control of patches and diskette-updates on a commercial database product. The completed experiment was a three month student programming project. In all but the student project developers have previous experience with other software configuration management systems. Results are collected from the experiments primarily by open-ended interviews [19] of the developers. The results are encouraging, the main benefits reported are:
Preserving context: Retrieving old releases, milestones, and stable “demos” are virtually effortless. Distributed, dynamic configurations: Being able to specify dependencies and relations locally and dynamically between versions is considered good—especially during experimentation where the software structure is changed often. Overview: One can directly query the prototype about structural- and file differences, obtain lists of all files in the context of a given version of a components, etc. Lessened selection problem: The developers are less often faced with the problem of selecting the right pieces for a configuration because the pieces themselves know their proper context. “Feels natural”: All developers expressed that they felt the approach natural. Even when the focus of their attention was on software configuration management and version control issues the approach allowed them to keep thinking in terms of their software design structure. Thus it seems that the approach bridges the gap between software development and software management.
Shadow problem: Presently the prototype requires its users to define part/whole- and reference relations manually; they are not inferred from e.g. the source code files because no language specific parsers are available. Thus if a relation is forgotten the context is not correctly specified.
Some other reported problems were more oriented towards the current implementation and user interface than the approach as a whole. The shadow problem may be avoided by having language specific parsers available that can match, say the #include’s in C++, against the relation sets in a component and report discrepancies2. The prototype may also provide a “copy-modify-merge” mechanism to avoid the rather coarse per-component locks. The pollution problem is interesting and discussed in the last section. RELATED WORK The context-preserving model resembles the three dimensional graph model proposed by Bendix [2] for integrating configuration management and version control. This model also sets distributed dependency information under version control but relies on generic configurations which means a selection mechanism is still essential to recreate context. Another similar approach is taken by Lin and Reiss in POEM [14, 15] where configuration management is made in terms of software units, a concept that resembles software components. Units relate to other units by uses links; selecting a specific version of a unit propagates proper selections to all units that it uses. However POEM seems to have no support for part/whole relations that are important to express a hierarchical structure. DSEE [13] relies on a centralised system model meaning that version selection engines are required to be able to recreate context for milestones and releases. As already noted modifying the software design structure means changing the system model which creates the problem of ensuring the synchronisation: Recreating an earlier version of a software part means first restoring the right system model used at the time of creation. PROTEUS [25] provides a strong configuration language, PCL, that allows describing a logical, hierarchical, structure superimposed on the physical file-structure and with strong 2 Lately the prototype has been extended with a Tcl interpreter [18] that
allows users to write such parsers themselves.
constructs for expressing variability. Still the system is described in a central system model giving rise to synchronisation and overview problems. CVS [4, 20] supports handling collections of files as a unit by versioning directories, and also part/whole relations by recursively operating on subdirectories. The module concept provides a limited way of handling reference relations also. The CVS concept “sticky-tags” enables branches to be made of a module. Again the module definitions in CVS is stored in a central, separate, module definition file. Another point is that CVS requires a team-wide consensus about what constitutes ’the latest version’ because CVS does not permit any developer to commit a change before his own working copies have been “updated” i.e. are identical to the latest version. In essence this feature of CVS prevents developers from having version control in workspace i.e. to use the versioning ability to create intermediate versions during experiments. CVS, RCS [22, 23], and MicroSoft Visual SourceSafe [17] relies on tags to define context. For example in a release situation all relevant files are tagged with a symbolic name. Tags have a number of deficiencies: A very pragmatic but nonetheless important consideration is that you have to remember to do the tagging; also tags are global so your stable library files very quickly contain numerous tags forcing you to continuously invent new tag names to avoid conflicts. In the context-preserving approach a version can have a symbolic name, but it is a local attributes of the version of the component, avoiding name-space pollution and name conflicts. FUTURE WORK Basically a software configuration management system must deal with two conflicting perspectives: The perspective of the project and the perspective of the individual developer. From the project point of view overview, control, traceability, and quality are crucial. Here it is important to have few, high quality versions that closely (if not one-to-one) reflects the achieved milestones and released versions of the product. From the developers point of view flexibility is important. A developer needs to experiment and in this process create intermediate versions as “safe ground”. A current effort is to provide better support for version control in workspace (see e.g. [3]) where the individual developer is allowed the flexibility of many, intermediate, versions in a local component storage and only affects the project-wide component storage when milestone-type versions emerge. Collaboration and collaborative awareness are other important themes in the current work. The context-preserving approach is seen as a strong framework because the distributed, dynamic, model for relations between components coarsely defines awareness. In the examples the developer or subteam responsible for component SoftwareComponent naturally needs to be informed about modifications made to components VersionGroup, Library, and RCSFile—because they
are all part of its context. Build management is an aspect of software configuration management that is presently unsupported in the prototype. However the outlined approach is seen as a strong framework because relations are an integral part of software components thus they will be able to respond to requests like “build” by propagating the build request throughout their context-graph. Software components can profitably be extended with a pool of derived objects to provide fast builds. Finally there is a need for more and larger experiments in order to test the scalability of the context-preserving approach. The main problem concerning testing a novel software configuration management approach, constrained by limited resources, in a large, realistic, setting is that the prototype must be proved very stable in order for anyone to dare putting their bulk of software under its control—a requirement that seems like a contradiction to the notion of a “research prototype”. However a new experiment has recently started in which the source code and technical documentation for the compiler in the Mjølner BETA System [1] is handled by Ragnarok. Based on the experiences from this experiment the full Mjølner BETA System source will be handled which will involve 8 developers and about 100 MByte of data. ACKNOWLEDGEMENTS Thanks to Ole Lehrmann Madsen, Jørgen Lindskov Knudsen, and the anonymous referees for many valuable discussions and comments. REFERENCES [1] P. Andersen, L. Bak, S. Brandt, J. L. Knudsen, O. L. Madsen, K. J. Møller, C. Nørgaard, and E. Sandvad. The Mjølner BETA System. In Object-Oriented Environments - The Mjølner Approach, pages 24–35. Prentice-Hall, 93. [2] L. Bendix. Configuration Management and Version Control Revisited. PhD thesis, Institute of Electronic Systems, Aalborg University, Denmark, Dec. 1995. [3] L. Bendix. Fully Supported Recursive Workspaces. In I. Sommerville, editor, Software Configuration Management, Lecture Notes in Computer Science 1167, pages 256–261. ICSE’96 SCM-6 Workshop, Springer Verlag, 1996. [4] B. Berliner. CVS II: Parallelizing Software Development. In USENIX, Washington D.C., 1990. [5] G. Booch. Object Oriented Design. The Benjamin/Cummings Publishing Company, Inc., 1991. [6] G. Booch and J. Rumbaugh. Unified Method for Object-Oriented Development. Documentation Set Version 0.8, Rational Software Corporation, Santa Clara/CA, 1995.
[7] H. B. Christensen. Ragnarok Component Model: Tutorial and User Manual. Computer Science Department, University of Aarhus, 1996. Available at URL: http://www.daimi.aau.dk/hbc/Ragnarok.html. [8] H. B. Christensen. Ragnarok: Contours of a Software Project Development Environment. Master’s thesis, Department of Computer Science, University of ˚ Arhus, 1996. DAIMI PB-509. Also available at URL: http://www.daimi.aau.dk/hbc/Ragnarok.html. [9] J. Estublier, editor. Software Configuration Management. Lecture Notes in Computer Science 1005. Springer Verlag, 1995. [10] A. Goldberg and K. S. Rubin. Succeeding with Objects, Decision Frameworks for Project Management. Addison-Wesley, 1995. [11] ISA. Consys. Available at URL: http://isals.dfi.aau.dk/, 1996. ISA: Institute for Storage Ring Facilities, University of Aarhus. [12] D. A. Lamb. Introduction: Studies of Software Design. In D. A. Lamb, editor, Studies of Software Design, Lecture Notes in Computer Science 1078. Springer Verlag, 1996. [13] D. B. Leblang and R. P. C. Jr. Parallel Software Configuration Management in a Network Environment. IEEE Software, pages 28–35, Nov. 1987. [14] Y.-J. Lin and S. P. Reiss. Configuration Management in Terms of Modules. In Estublier [9]. [15] Y.-J. Lin and S. P. Reiss. Configuration Management with Logical Structures. In Proceedings of the 18th International Conference on Software Engineering, pages 298–307, 1996. [16] B. Meyer. Object-oriented Sofware Construction. Prentice Hall International Series in Computer Science, 1988. [17] Microsoft (R) Corporation: Visual SourceSafe. Available at URL: http://www.microsoft.com/ssafe/. [18] J. K. Ousterhout. Tcl and the Tk Toolkit. AddisonWesley Professional Computing Series, 1994. [19] M. Q. Patton. Qualitative Evaluation Methods. Sage Publications, Beverly Hills, Calif., 1980. [20] Signum Support AB: CVS – Concurrent Versions System. Available at URL: http://www.loria.fr/molli/cvs/doc/cvs toc.html. [21] I. Sommerville. Software Engineering. Wesley Publishers Ltd., 4 edition, 1992.
Addison-
[22] W. F. Tichy. Design, Implementation, and Evaluation of a Revision Control System. In 6th Conference on Software Engineering, Tokyo, Japan, 1982. [23] W. F. Tichy. RCS – A System for Version Control. Software – Practice & Experience, 15(7):637–654, July 1985. [24] W. F. Tichy. Tools for Software Configuration Management. In J. F. H. Winkler, editor, Proceedings of the International Workshop on Software Version and Configuration Control. B. G. Teubner, Stuttgart, Jan. 1988. [25] E. Tryggeseth, B. Gulla, and R. Conradi. Modelling Systems with Variability using the PROTEUS Configuration Language. In Estublier [9].
