[sugar] adding versions to journal/datastore
Eben Eliason
eben.eliason
Wed Oct 1 16:08:38 EDT 2008
On Wed, Oct 1, 2008 at 3:49 PM, Walter Bender <walter.bender at gmail.com> wrote:
>> Walter, could you elaborate on your comment?
>
> My comment was in regard to the anticipated additional complexity we
> may run into if/when we have versioning between multiple users, as
> would be dictated by most of the bulletin board schemes. Not sure if
> Tomeu's model will work, but it doesn't seem a bad first step.
I see. I think we partially circumvent the complexities by
restricting the notion of versions to, in the end, a flattened tree.
That is, the user isn't concerned with the details of branching
structure. Instead, the most recent version (from any "branch") I've
resumed is the one that sits at the top of my Journal. This is
consistent with the Journal as a time-based structure, because the tip
of that new branch I created was created last in the timeline.
When you have several kids, potentially with different versions of the
same activity, they can all get back together, do manual merges, and
then continue work in whichever instance they choose. When they all
stop working on that implicitly agreed upon "true version", that then
becomes the tip, and the latest entry for all of them in the Journal.
This model does, of course, eliminate (at least with the current UI
proposal) potential advantages of a truly hierarchical versioning
scheme, but I think it simplifies specifically to the point you raised
earlier, which is that "the last thing I did" will be the most
important thing to me.
- Eben
PS. The one place this causes problems is when you go back to an old
version, rename it with the intent to use it as a base for a
completely different project, and then work from there. In this case,
you really want to have a new root node, instead of a new version. We
should discuss the implications here, and if we might want to "create
a copy" (a new root node that contains the contents of the copied
node) on rename.
> -walter
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
More information about the Sugar-devel
mailing list