Reasoning behind the OSMIC proposal:
MODELS OF TIME,
BACKTRACK AND GROUPWARE
1) ways to think about time; and being gods, how best to define it;
3) models of versioning (especially version states available, past and future);
2) the different undo options to make available;
4) the issues of file locking-- who has the right to do what to which, how and when.
The OSMIC prototype software is intended to help us experiment with, and think about, all of these.
Similarly, in current groupware models, versions must be "checked in" and "checked out", and all users inherit the latest changes on a document.
This is naive because there are many reasons you may want to use previous versions, or branch from previous versions.
(I am told that the experience among users of Lotus Notes is that different versions do not need to be resolved; users generally find they only need to understand their differences.).
These naive models of time and versioning generate two popular models: circular flip-flop undo, and linear sequential undo.
Actually, for completeness we should add one more state. If the user chooses to discard previous work and go back to a saved version ("revert" on the Macintosh), this allows one previous state to be accessed, usually a much earlier state.
FLIP-FLOP UNDO with reversion
This of course loses both the current and previous state.
Here we need to represent the sequence of states of a document. Beginning with an empty state S0, the user applies a series of editing operations
As in flip-flop undo, the user can go back to the previous operation--
However, in linear undo it is possible to continue to
undo a sequence of previous operations, undoing them backward one at a
In some of these, it is possible to go forward again, meaning that the sequence of operations has not been not lost, only tentatively deleted.
It is not until the user makes a DIFFERENT change that the forward sequence of changes is lost. Consider the previously shown backtrack to state S5.
If the user now chooses (at state S5) to make a different change, then S6, S7, S8, S9 are lost forever.
However, it does not have to be that way. The previous
work (states S6, S7, s8, s9) do not have to be lost. There is a good
case for preserving all possible states of a branching series of edit operations.
That is what OSMIC demonstrates.
The most common approach is "file locking", where one user checks out a file and may change it. This prevents two people from making contradictory changes on the file at the same time (in which case whoever presses "save" first wins).
However, this generally forces everyone to accept the work that others have previously done in the sequence, and cuts off the option of returning to an earlier state.
More importantly, it prevents working in parallel. It also does not achieve the goal of allowing people to make different kinds of changes on the same material which may contradict each other at first, but which may later be reconciled-- in other words, working separately in parallel, as we should be able to do.
In the current prototype, you may go to any microversion of a branching document.