User representation of orgls & berts

[Eric Dean Tribble <tribble>]

I agree with your constraints with one reservation. We must provide AT
LEAST Save/Revert/etc functionality, but we are not restrained from
having more (if it's easy).

One more constraint:  what ever we provide should be upward compatible
with a better solution.  The other side of this is that this is an
exemplar and we shouldn't hack some grisly thing together.

   THE SOLUTION:

   All the itty bitty edit operations back to the last Save/Save As/Revert
   are kept as a series of stamps in the historical trace for the usual
   editor-type Undo operations. They are all thrown away on a Save/SaveAs/Revert
   (at least from the trace).

Which of these need confirming by the user?  The current edit Bert
should probably be added to the historical trace before reverting,
just in case the user wants to undo the revert operation.

   A Save marks a checkpoint, i.e. a node in the version tree of the document.
   For simplicity at the moment, we will suppose that these are kept in a
   separate trace from the edit operations. These nodes are put on the
   historical trace in a linear sequence in the real-time order of creation.
   This becomes important when looking at forking versions:

This is exactly what happens when using a changeRecorder on a Bert.  A
partial Orgl gets filled in with successive Stamps from the Bert,
indexed by a timeStamp of some sort.  Therefore, a Save just hops the
Bert associated with the document (as opposed to the edit session).  A
SaveAs makes a new Bert and historical trace onto the current edit
Orgl.

   A Revert walks back on the timeline to the most recent node. An UnRevert
   (Cancel Revert? Revert Forward? Prevert? ;-) goes to the node after
   the current one in the trace. Starting to edit after a sequence of
   Reverts/UnReverts puts another copy of the node at the end of the
   historical trace. Thus Revert/Unvert will visit all checkpoints in
   the document at least once, and once more for each branch if the document
   branches into several versions at that point. A sample session:
   (The "current" version is parenthesized)

I can't quite parse this, but the diagram made sense (and was quite
good! Thanks).  Let me modify it to reflect the bahavior using the
ChangedRecorder.

   Version Tree		Historical Trace	Command

...						   ...edit...
						   Save
   A-B-C-(D)		A,B,C,D
						   Revert
						   Revert
   A-(B)-C-D		A,B,C,D,C',B'
						   ...edit...
						   Save
   A-B-C-D			A,B,C,D,C',B',E
      \
       (E)

Note that C' and B' are new Stamps (they record that the Bert was
hopped to another state).  Thus the sequence of reverts woud be
E,B,C,D,C,B,A.  Note that using the BertChange Recorder is the
simplest solution to the problem.

   A sequence of Reverts at this point would visit versions E,B,D,C,B,A
   in that order.

How much better is this than the above?  I think we should avoid
modifying obvious structures that the backend provides.  If we need to
do so,  then either the semantics need fixing, or the idea is at a
higher level than the semantics and we should make sure that we
implement a subset of the RIGHT solution (choirs of angels in the
background).  If the latter, then we should sketch the right solution
and then implement the minimal interesting subset of it.

dean