Hi Folks, Andre just found an issue (thanks, Andre) with restoring two different collections with multiple versions of the same recurring item.
To reproduce the problem, just take a recurring event, put it in two collections, then start with a new repository and restore both collections. There are timing issues, but you can generally get either a merging error or a stale item error. What's happening is that the various sharing threads are, in parallel, creating the same recurring event, then either: A) in one thread, the sharing code deletes occurrences used by the other thread (and the UI thread) leading to stale item errors or merge errors, or B) the master occurrence ends up with two duplicate sets of occurrences from each sharing thread, because the masters share a UUID and can be merged between views, but occurrences don't share UUIDs Grant and I discussed several ways of fixing this. We could doing share restore in parallel, and instead queue up all the collections to be subscribed to. This would slow down share restore, but would lead to fewer merge errors. We could also make occurrence UUIDs be derived from master UUIDs, so the repository could merge occurrences together rather than allowing duplicate occurrences. A scheme to do this might be to use a formula like: occurrence_uuid = md5(master_uuid + recurrence_delta) where recurrence_delta is the string representation of the occurrence's recurrence_id's timedelta from the master's start time. Thoughts? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
