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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
