Den 08. aug. 2012 02:42, skrev Ove Kåven: > As far as I can tell from the sources, at least KCalExtended's Tracker > storage stores and selects on the stamp of the time stored in the > received entry, not the local time of reception. > > It makes sense that the created-time and modified-time in the entry > should be the time the *user* modified the data, otherwise sane conflict > resolution becomes impossible. Thus, I'd say an implementation that does > what you say is broken. (I did see one instance of possible brokenness > in KCalExtended's SQLite backend regarding the created-time, but not in > the Tracker backend, which is probably what's actually used here.)
Checked again, and it seems that's not the case. It's using the SQLite backend, not the Tracker backend, Still, even there, the last-modified-time remains untouched from what the peer provides, only the created-time seems to get overwritten. I suppose syncevolution does not care about the difference between inserts and updates. If modifiedIncidences also sees inserts, it might be fine to just not use insertedIncidences (which checks created-time), and rely solely on modifiedIncidences, to get the behaviour we want. I guess I'll do some checking. Anyway, yes, even if this works, this kind of change tracking is not ideal since it's only reliable if we only sync with *one* peer, not many. But these are consumer devices, it's probably fine to assume that, that's what users are used to. Otherwise, perhaps the backend should have a config option to give it a more TrackingSyncSource-like behaviour, slower and requires more storage, but works with multiple sync peers? _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
