21
The problem with undo in group work is that many of the simplifying assumptions possi-
ble in a single-user editor are simply unreasonable in a multi-user situation. For instance,
one thing that requires modification is the notion that a user’s changes can be undone in
the reverse order that they were performed, even though one good way to resolve a conflict
among users is to simply undo some of the problematic changes. The linear undo model fails
because a user’s own changes may have been followed by changes made by other users, so
that undoing one’s own changes is impossible without also undoing those made by another
user, even if they occur in another part of the object being edited. The same situation can
occur any time a user attempts to undo any change, in fact, since the order of user notifica-
tion of changes not infrequently varies from editing instance to editing instance.
As in a number of other areas of collaborative editing, synchronous and asynchronous
editing have been handled differently, and most systems have concentrated on one or the
other. The synchronous case has received the most attention, as undo is one of the problems
that crops up immediately once simultaneous editing is enabled. One approach is to rewind a
historical log of changes and then replay them, without the change to be undone, and then
broadcast a change cancellation to the other instances of the editor. This approach is taken
in (Prakash and Knister 1992; Choudhary and Dewan 1995). These systems extend opera-
tional transformation to support this, by using it to transform operations before redoing
them. Local editors must retain enough history to backtrack and undo specific operations.
This technique does not work so well if off-line as well as on-line collaboration is supported
by the system, since the number of changes involved can be quite large, even for a relatively
short editing period.
In fact, algorithmic solutions have been rather sparingly applied to this problem in the
asynchronous case, exactly because the typical divergence between separate long-term
transactions is large. The focus has generally been on preventing conflicts by means of
locking or versioning (as in the software-engineering domain) or on the detection of
The problem with undo in group work is that many of the simplifying assumptions possi-
ble in a single-user editor are simply unreasonable in a multi-user situation. For instance,
one thing that requires modification is the notion that a user’s changes can be undone in
the reverse order that they were performed, even though one good way to resolve a conflict
among users is to simply undo some of the problematic changes. The linear undo model fails
because a user’s own changes may have been followed by changes made by other users, so
that undoing one’s own changes is impossible without also undoing those made by another
user, even if they occur in another part of the object being edited. The same situation can
occur any time a user attempts to undo any change, in fact, since the order of user notifica-
tion of changes not infrequently varies from editing instance to editing instance.
As in a number of other areas of collaborative editing, synchronous and asynchronous
editing have been handled differently, and most systems have concentrated on one or the
other. The synchronous case has received the most attention, as undo is one of the problems
that crops up immediately once simultaneous editing is enabled. One approach is to rewind a
historical log of changes and then replay them, without the change to be undone, and then
broadcast a change cancellation to the other instances of the editor. This approach is taken
in (Prakash and Knister 1992; Choudhary and Dewan 1995). These systems extend opera-
tional transformation to support this, by using it to transform operations before redoing
them. Local editors must retain enough history to backtrack and undo specific operations.
This technique does not work so well if off-line as well as on-line collaboration is supported
by the system, since the number of changes involved can be quite large, even for a relatively
short editing period.
In fact, algorithmic solutions have been rather sparingly applied to this problem in the
asynchronous case, exactly because the typical divergence between separate long-term
transactions is large. The focus has generally been on preventing conflicts by means of
locking or versioning (as in the software-engineering domain) or on the detection of
