[Design] annotations in Chandler
mimi at osafoundation.org
Thu Nov 10 10:49:29 PST 2005
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
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.
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
> 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.
More information about the Design