http://bugs.meego.com/show_bug.cgi?id=1790 Summary: [Watching 1364] SyncML server: conflict resolution Classification: MeeGo Platform Product: OS Middleware Version: 1.0 Platform: Netbook OS/Version: IA Status: WAITING FOR UPSTREAM Severity: normal Priority: Undecided Component: SyncEvolution AssignedTo: patrick.ohly(a)intel.com ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs Estimated Hours: 0.0 Patrick please focus on bug#1364, I will keep this updated. Not propose it to be MeeGo-1.0 blocker, for it is not a blocker issue. Description From pohly 2010-02-12 08:39:48 PST (-) [reply] Steps to reproduce: - setup SyncEvolution as client of a SyncEvolution - get client and server in sync with a single task - modify task on client and server - sync - sync again - ... During each sync, client and server swap their items. They are never really in sync. Either the server should preserve one task during the conflict resolution or both, but not permanently send data around. Might be possible to reproduce with other data, not checked yet. ------- Comment #1 From pohly 2010-02-12 08:42:37 PST (-) [reply] ------- This happened while doing slow syncs. With two-way syncs, conflict resolution preserves only one task, as intended. Nevertheless, slow sync should have worked, too. ------- Comment #2 From pohly 2010-04-19 08:29:07 PST (-) [reply] ------- This can be simplified: - clear all items on a server which uses the file backend - slow sync with one item on client A - modify item on client A so that a key element differs (like SUMMARY in task) - slow sync again Expected result: - client and server in sync, either with one item or two Actual result: - server has two items, client one (the unmodified one from the initial sync) The root cause is that the server treats these two items as different when using the file backend, because neither that backend nor the engine know about the significance of the UID property, which happens to be identical here. In the second slow sync, it sends an <Add> command with the item that it had from the initial sync. The client then turns the <Add> into a <Replace> of the item that it just sent to the server, overwriting the local, more recent data with the older copy from the server. The client uses the EDS backend, which detects that the new item from the server has the same UID as a local item, and therefore it *replaces* that item instead of adding it anew. IMHO the correct solution would be for the server to detect that two conflicting items have the same UID. The UID of the item on the server then must be replaced with something which satisfies the iCalendar 2.0 "globally unique" criteria before it is sent to the client in an <Add>. Or the property must be cleared, which will cause the client to create a value. I have no idea how to implement either one or the other, though. Solutions which don't work: - Compare only the UID property. A) we don't know whether the client really provides a stable, globally unique UID and b) we would end up with only one item even when both items were modified and thus should both be preserved. - Don't store UID on the server. We want it there for backup/restore of iCalendar 2.0 clients. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.