[Sugar-devel] GSoC proposal: version support for data store and Journal

[Eben Eliason]

On Fri, Apr 3, 2009 at 7:49 AM, Sascha Silbe
<sascha-ml-ui-sugar-devel at silbe.org> wrote:
> On Thu, Apr 02, 2009 at 05:36:41PM -0400, Eben Eliason wrote:
>
>> In all of our preliminary designs, we actually proposed that branches
>> be flattened from the perspective of the user. That is, the most
>> recent head of any branch in a tree is the "canonical version" which
>> appears as the most recent entry in the Journal.
>
> So you intended to display one version per branch, with intermediate
> versions available from a details view?

No, actually, the opposite. Basically, all versions of a document
would appear within the list view timeline. Their order within the
list would be determined by their timestamp. If I work on 3 iterative
versions of a document, then go back to the second version and make
changes, I get a new 4th version which appears as the most recent item
in the Journal. It doesn't matter (at least here) that I technically
have a branch at version 2, which has children 3 and 4. What matters
in the Journal perspective is that I worked on version 4 most
recently. The tree is flattened into a list in the time dimension.

This is also the reason that the latest Journal designs split the UI
into "action" and "object" views. The action view would be a temporal
history of everything you've done (with each version through time).
The object view would represent each object only once, by it's most
recent version, thus providing a much shorter list.

>> If you look at the designs on the wiki, you'll actually note that the
>> date in the detail view is a popup.
>
> Now you point it out I see it. :)
> Interesting idea.
>
>> Additionally, each version would appear in the list/timeline view of the
>> Journal, so that you could just as easily scroll "back in time" to several
>> days ago when you made the first version of a document, and resume that
>> directly from there.
>
> Hmm, I'm not sure I understand how this fits with what's said above... Is
> the above for the non-timeline view or do you intend to "split" the list and
> show only the latest version of each branch _per_ _buffer_ (buffer def. as
> in #8)?

Hopefully the above clarified my thoughts in this area.

> [Version tree view]
>>
>> I'd probably recommend against this, both because I think there's far
>> more work to be done to get this working smoothly than you might
>> think, and because I don't think it's actually an important feature
>> for kids.
>
> To me, it's a very useful feature for debugging and should definitely be
> there. Whether somewhere deep in the Journal or in a separate "Datastore
> Explorer" activity is a separate matter, though.

There has been much arguing over where this lived, or if we should
have it. The argument was last settled by stating that it should be
possible to add, but that it's certainly not required for useful
version support which is, more than anything, needed to prevent loss
of data. A flattened list of versions gives us that in the Journal
paradigm without the need for understanding trees.

If it is to be added, I could potentially see it appearing in details,
or perhaps when expanding items in the object view of the Journal to
show their histories.

Eben

> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJJ1ffjAAoJELpz82VMF3DaPiwH/1pNK96vNjWBy44qd/u8zw2M
> n9UwVIzaYF3IJ87tQwGFcsN6lFgPK5lbxdNXeIWYJidhytODBvmZWuRPDreW258w
> adapHKKsl3F2F5SZLY89eZ0ztrKxy3H0ahsIda81bwFOOYkzWt0iB9OH/i8kClyh
> OYMlfa5CRhiU1iTjlUWm6SjVACRKCgfDT1YumbCDTGGbsjKYFfUZHVBganADBdfl
> al6XqV2408VKMtanujNk0WZeSTCUcKFh0f1l2lbykdqDI/mMOmcOT6EtY05mE9E6
> Pl0fEezEHd0iXeCXTFLrjoFZvAFrEZhkvUFWjDrCjqL2q46+m1eus4A8LV8eQuI=
> =zaxY
> -----END PGP SIGNATURE-----
>
>