[Sugar-devel] [IAEP] Sugar Digest 2009-07-28

[Gary C Martin]

On 29 Jul 2009, at 02:07, Martin Sevior wrote:

> On Wed, Jul 29, 2009 at 7:48 AM, Walter  
> Bender<walter.bender at gmail.com> wrote:
>> ===Sugar Digest===
>>
> <snip>
>> Here is where the trouble began. First of all, the version of Turtle
>> Art I used to build the game is newer than the version they had
>> installed on their machines. Normally, this wouldn't be an issue, but
>> I had used a block that they didn't have, so the sharing halted part
>> way through. The good news is that Sebastian Dziallias pushed a  
>> change
>> for Sugar on a Stick to contain all activities packaged as XO files,
>> meaning that all activities can update. (Presently, it is non-trivial
>> to update activities that had been distributed as RPM.) The bad news
>> is, Turtle Art, being part of Fructose, had been distributed as RPM  
>> on
>> the Gardner School sticks. So I will have to update them by hand.
>>
>> But had sharing worked, I still would have run into some problems,
>> since once, shared, always shared. I discussed the problem with Ben
>> Schwartz in IRC:
>>
> <snip>
>
> Hi Walter,
>              Here is what we decided to do for AbiWord collaboration
> to our web service (http://abicollab.net) when faced with this
> problem.
> If a user does a "save as" the document is saved locally (rather than
> remotely) with a different name. If the user also drops out of the
> collaboration all the changes she makes will made to the local file.
> At this point the document is forked and as things currently stand
> cannot be automatically merged back into the original. Of course it
> can be manually merged via cut/paste etc.
>
> I'm not sure this is sufficient for what you need but I think it is
> sufficient for documents at least.

There are a lot of issues related to the current Sugar sharing (and  
versioning) model. I've always wanted to be able to "Stop Sharing"  
something (and rarely share anything other than when testing, due to  
the lock-in and potential mess created).

Perhaps it would be sensible that 1) you can stop sharing, 2) as you  
stop sharing the activity it becomes the equivalent of a new  
activity_id (in today's implementation)**. This would allow you to  
collaborate on an activity, stop sharing and work on it locally, start  
sharing it again later for more collaborative work but now being a NEW  
activity it would be yours and would NOT be auto merged with the  
original N others.

Stopping an ongoing shared activity and resuming later would attempt  
the auto-merge by default.

Think this roughly equivalent to Martins "save as" process, and also  
similar to bemasc idea on using "make
a template copy".

** perhaps it could be a version bump rather than new activity_id,  
where collaboration only persists for same activity_id & version?

Regards,
--Gary