Configuration Management and Version Control Revisited

ed Context Figure 5.4. How to describe a configuration. This way of adding and shadowing/redefining relations resembles very much the way scope rules work for identifiers in nested blocks in programming languages. In fact, for context one we could consider layer C to be nested in layer B which is again nested in layer A. For instance, for procedure Pn from figure 5.3, context one will consist of the layer A nodes for definition and declarations, the layer B node for comments and the layer C node for implementations. When a configuration is installed (or generated) it is always done relatively to a context, which resolves the layer hierarchy. There are two types of contexts: abstracted and concatenated. The abstracted contexts are direct descriptions of the dominance hierarchy, while the concatenated contexts are formed from putting together subcontexts. The difference is that in figure 5.4 the abstracted context gives the dominance hierarchy ABCDE (from least to most dominant), while the concatenated context gives ABCADE. Thus the second occurrence of the layer A shadows for changes made to this layer in layers B and C. However, if the subcontexts are independent this will not cause problems. PIE also supplies an interface for comparing layers and contexts, thereby making it easy to merge two layers into one. The interface highlights the difference between two layers, and the user can then choose the (node, attribute, value) triples that he wishes and copy them into a merge layer. When this layer is added to the context, it can dominate the old layers. Thus merging of layers (versions) is considered an operation that has to be performed explicitly and separately from the version control.