36
2. User actions should be reflected.The operations made visible to a user by merge and
undo facilities should be operations actually performed.Both this and the preceding
requirement are both justifications for the following requirement.
3. Move and copy should be supported.If we limit the kinds of changes allowed by the
model, we are likely to fail the reasonability requirement. Move and copy are ex-
tremely common operations and they should be first-class citizens. Tracking move
and copy allows data sharing to be used in determining reasonable merge results (as
when one change edits data, and another moves or copies it).
4. Determinacy of merge results.It is important that the system have a consistent, well-
defined model for determining the result of interacting changes in a merged group of
changes. Practically speaking, editing conflicts should be resolvable simply by un-
doing the change that creates a conflict. The definition of what conflicts are resolved
by user or the system remains an application function.
5. Local tracking of changes.It should be easy for the system to provide information on
the changes that affect any particular parts of the shared object.
6. Commutativity of changes.In order to support the full flexibility of merging, changes
must not have inherent ordering requirements with respect to each other. Changes
should have two states: active and inactive. Where ordering is unavoidable we prefer
to have the system do it, preserving the simple user model of merge, rather than
adding the relative ordering of many asynchronously made changes to the user’s
collaboration management workload.
7. Simple conflict tests.Some changes can conflict with other changes. Detection of
such conflicts should involve simple tests, in order to enable quick conflict detection
and acceptable implementation cost.
8. Guarantee of sensible results.Given a system’s deterministic answer for a combination
of changes, that result should be as sensible as possible. However, a deterministic re-
2. User actions should be reflected.The operations made visible to a user by merge and
undo facilities should be operations actually performed.Both this and the preceding
requirement are both justifications for the following requirement.
3. Move and copy should be supported.If we limit the kinds of changes allowed by the
model, we are likely to fail the reasonability requirement. Move and copy are ex-
tremely common operations and they should be first-class citizens. Tracking move
and copy allows data sharing to be used in determining reasonable merge results (as
when one change edits data, and another moves or copies it).
4. Determinacy of merge results.It is important that the system have a consistent, well-
defined model for determining the result of interacting changes in a merged group of
changes. Practically speaking, editing conflicts should be resolvable simply by un-
doing the change that creates a conflict. The definition of what conflicts are resolved
by user or the system remains an application function.
5. Local tracking of changes.It should be easy for the system to provide information on
the changes that affect any particular parts of the shared object.
6. Commutativity of changes.In order to support the full flexibility of merging, changes
must not have inherent ordering requirements with respect to each other. Changes
should have two states: active and inactive. Where ordering is unavoidable we prefer
to have the system do it, preserving the simple user model of merge, rather than
adding the relative ordering of many asynchronously made changes to the user’s
collaboration management workload.
7. Simple conflict tests.Some changes can conflict with other changes. Detection of
such conflicts should involve simple tests, in order to enable quick conflict detection
and acceptable implementation cost.
8. Guarantee of sensible results.Given a system’s deterministic answer for a combination
of changes, that result should be as sensible as possible. However, a deterministic re-
