Hi Morgen, >> 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. > > I think this also means never having more than one sharing operation > going at any given time, including background syncs, and subscribes, right?
Blocking subscribe workflows during a background sync doesn't seem like a good outcome. I couldn't remember the circumstances in which parallel sharing threads are likely to happen, but that's it. That makes me lean away from avoiding parallel merges, instead we can think of parallel restores as a good bug finding tool for those rare simultaneous subscribe/background sync cases. :) Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
