---- Reported by jingke.zhang@intel.com 2010-04-26 19:47:13 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=9682

   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.



--- Bug imported by patrick.ohly@gmx.de 2012-08-19 20:56 UTC  ---

This bug was previously known as _bug_ 1364 at https://bugs.meego.com/show_bug.cgi?id=1364

Unknown platform unknown. Setting to default platform "".
Unknown operating system unknown. Setting to default OS "".