102
operations. The only constraint actually enforced by a system is that before checking in the
new version the user who created a newer version at least had the opportunity to look at
(and edit) its predecessors. In practice, of course, succeeding versions usually usually are the
result of editing the previous version, and systems take advantage of this fact, using diff
algorithms to optimize the storage of versions.
5.1.1 Representing traditional version graphs in Palimpsest
A Palimpsest model of traditional software engineering-style versioning approaches like
those in, e.g. (Rochkind 1975; Tichy 1985; Cohen, Soni et al. 1988). Consider a branching
system without merge. A Palimpsest model of this system uses change sets to represent each
node in the version graph. Each change set corresponding to a node would be a superset of
the change set representing its parent node, corresponding to the fact that it was derived by
adding changes to its parent.
Adding merge to such a system potentially introduces problems, in the case that compo-
nent changes conflict. When no conflicts are present, a merge result is obtained simply by
taking the union of the two parents. This result would then serve as the base for any user
corrections to the result of the merge, in the form of additional changes to the merged ver-
sion. In the presence of conflicts, there are two possibilities. The simplest is to eliminate
conflicts by amending the address ordering as discussed in Section 4.3.2. This simple possi-
bility, however is rather different from the policies of the systems that we are trying to
emulate.
An alternative apporach is the create an initial merge result representing a conflict-free
union of the changes in the two parent versions. The conflicting changes would be stored in
a separate change set for hand intervention by the user, operation-by-operation. In this
case, the mechanical merger would serve as a starting point for the user to create a final
merge result. This is essentially similar to the merge facilities in most software configuration
management systems, which detect differences, and then offer the user the opportunity to
operations. The only constraint actually enforced by a system is that before checking in the
new version the user who created a newer version at least had the opportunity to look at
(and edit) its predecessors. In practice, of course, succeeding versions usually usually are the
result of editing the previous version, and systems take advantage of this fact, using diff
algorithms to optimize the storage of versions.
5.1.1 Representing traditional version graphs in Palimpsest
A Palimpsest model of traditional software engineering-style versioning approaches like
those in, e.g. (Rochkind 1975; Tichy 1985; Cohen, Soni et al. 1988). Consider a branching
system without merge. A Palimpsest model of this system uses change sets to represent each
node in the version graph. Each change set corresponding to a node would be a superset of
the change set representing its parent node, corresponding to the fact that it was derived by
adding changes to its parent.
Adding merge to such a system potentially introduces problems, in the case that compo-
nent changes conflict. When no conflicts are present, a merge result is obtained simply by
taking the union of the two parents. This result would then serve as the base for any user
corrections to the result of the merge, in the form of additional changes to the merged ver-
sion. In the presence of conflicts, there are two possibilities. The simplest is to eliminate
conflicts by amending the address ordering as discussed in Section 4.3.2. This simple possi-
bility, however is rather different from the policies of the systems that we are trying to
emulate.
An alternative apporach is the create an initial merge result representing a conflict-free
union of the changes in the two parent versions. The conflicting changes would be stored in
a separate change set for hand intervention by the user, operation-by-operation. In this
case, the mechanical merger would serve as a starting point for the user to create a final
merge result. This is essentially similar to the merge facilities in most software configuration
management systems, which detect differences, and then offer the user the opportunity to
