If a user edits items while a synchronization is running, then all kinds of "interesting" things can happen: change is overwritten by server change (definitely!), change is made locally but never sent to server (not so sure), ... Part of the problem is that the EDS API is prone to race conditions. This needs to be fixed first, as discussed with the EDS developers: http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html Since that discussion I have implemented automatic restore from backup, which has changed my view on the necessary APIs a bit: it would be nice to store items with a specific REV or LAST-MODIFIED if the libebook/libecal user knows what he is doing. Not bumping these fields when restoring an items has the advantage that other clients which were in sync with the restored data don't see any unnecessary changes. The other part of the problem is getting a set of item ID + revision string (REV for contacts, LAST-MODIFIED for event/tasks) in an atomic way. I'm not sure whether the current methods are really atomic. But worse, they are also much slower than they could be because we have to transmit the whole content of the database via D-Bus just to extract the much smaller set of required information. Ross wanted to work on a call to return pairs of UID+REV for libebook. I don't think he got very far with that, though. I think this is a fairly import optimization.