[Design] annotations in Chandler

[Mimi Yin]

Does any of this change if we say that sharees (via both email and  
sharing) only need to keep versions that have been capital-N 
(otification) in sync?

So if I take Version 5 and edit it, but don't sync it, it's really  
Version 5.xx
Then someone sends me Version 6, but I can keep my Version 5.xx as 5.xx.
And when I see this item in collections and what not, I can either  
choose to only see the latest version (V6) or I can selectively  
choose to see earlier versions as well: V5.xx, V4, etc..

So people might have different .xx (minor) versions, but the Major  
versions V5, V6 would be in sync.

Mimi

On Nov 10, 2005, at 10:04 AM, Morgen Sagen wrote:

>
> On Nov 9, 2005, at 10:29 PM, Alec Flett wrote:
>
>> We could include version information along with sharing  
>> information when we post CloudXML to cosmo, then you could "play  
>> back" the changes within your repository, and commit in between  
>> each change so that your repository versions match the version set  
>> you just downloaded.
>>
>
> One problem is that while we could add additional version info to  
> CloudXML (basically replacing CloudXML with a log of changes), just  
> about all CalendarEvent properties are shared via iCalendar (.ics)  
> resources, which we don't really have the ability to change the  
> format of.
>
>
>>
>> If we did that, the next technical hurdle would be to sync up the  
>> versions in the situation where:
>> 1) I share something, say at version 5
>> 2) I make an edit locally, it becomes a local version 6
>> 3) Someone else makes an edit locally, and syncs back to the  
>> server, it becomes version 6 on the server
>> 4) A third person makes an edit locally, and syncs back to the  
>> server, it becomes version 7 on the server
>> 5) I sync with the server - in order to be in sync with the  
>> server, we'd need to roll  back to version 5, apply the changes  
>> from 6 and 7, and then apply our local version 6 change, which  
>> becomes version 8, and apply that up to the server.
>>
>> Actually, I think morgen does something like this already in his  
>> merging-with-views...
>>
>
> Well, the experimental (and disabled for 0.6) view merging would  
> still see all remote changes as a *single* change.  However, the  
> "V" in WebDAV stands for Versioning, so perhaps we could leverage  
> the server's versioning capability to track individual remote changes.
>
> ~morgen
>