[sugar] adding versions to journal/datastore

Benjamin M. Schwartz bmschwar
Wed Oct 1 16:16:34 EDT 2008

Hash: SHA1

I very much like Tomeu's version model, but I am also unsure whether I
have interpreted it correctly.

My feeling is that each object in the Journal is associated with a tree of
versions.  The tree has one node with no ancestors: the root node, which
represents the initial version.  The tree also has at one or more nodes
with no children: these are the "leaf" or "tip" nodes, which represent the
most recent versions.  Resuming any version and editing it produces a new
node whose ancestor is the node of the version that was resumed.  An
editing session that contains many incremental saves may produce a long
chain of such nodes.

~From a user interface perspective, I think the idea is extremely simple.
Each object is actually a leaf from the version tree, and the detail page
of an object shows its predecessors.  This does not conflict with the
Actions view of the Journal or the Objects view.  The history of an object
is only visible in its detail page.  Under normal circumstances, editing
an object causes that object to move up toward the top of the Objects
view, but does not cause any duplication.  Keep also does not induce a
duplication; it just ensures that a new leaf node is made for the current
state.  The only way to duplicate an Object is to explicitly resume an old
version from the version history in the details view.  When that resumed
instance is saved, either automatically or through the Keep button, a new
leaf node is created, and so a new entry appears in the Objects view.

Adopting this idea would make the current Journal behave like the
future-designs Objects view, with each object appearing only once, rather
than once for every time it has been edited.  We may then add a separate
Action view to complete the future-Journal.

- --Ben

Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Sugar-devel mailing list