[Sugar-devel] On datastore object IDs

[Eben Eliason]

On Thu, Jul 2, 2009 at 3:54 PM, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> Eben Eliason wrote:
>> Having said all that, it now seems clear to me that what I'm actually
>> concerned with is doing merges when v_x and v_y are the "most recent"
>> versions belonging to the individual who resumes them. No matter how
>> many new versions kids A and B make, a merge should be attempted
>> between their newest versions, but only their newest versions.
> ...
>> Do you agree
>> with my thought process here?
>
> I think I understand what you're saying.  From an interaction design
> standpoint, you're saying that if someone deliberately opened an old
> version, that's a good indication that they don't want the latest stuff,
> so the system shouldn't automatically connect them to the shared session
> and merge in everyone else's changes.

Right.

> I can't quite say I "agree".  For example, I may have made some changes to
> the document, but decide I'd rather keep those changes local, and only
> merge back in with the group using some older version.  Conversely, I may

This is an interesting use case. Perhaps an activity could have a
"Merge with others" (Or "Join with others"?) option in the activity
palette anytime that another version with the same tree_id is running.

> decide that I want to edit the latest version privately, even though

The first part here, taken alone, could be satisfied by a "create a
copy" button. As discussed before, there should be a way to take any
object and make it the root of a new tree, with a new tree_id. Of
course, this pulls you out of the history completely, meaning you'll
never be able to merge that back into the old history (except
manually, of course).

> there's a shared session going on, with the understanding that once I'm
> ready I'll be able to join and merge in.

I don't have a good suggestion for this. However, that might be OK. We
might take the stance that real-time collaboration the preferred model
when it's possible. It seems like enabling async collaboration even
when sync collaboration is possible is only worth even thinking about
if all activities have support (and good support, at that) for
automatic merge. Otherwise we're just inviting conflicts.

If this is really wanted, I guess I could see adding a "Work alone"
action which would be the inverse of "Join with others".

Eben

> I think your suggestion is a good heuristic, but it would be nice to be
> able to override it.
>
> --Ben
>
>