---- Reported by patrick.ohly@intel.com 2011-08-29 13:46:42 +0000 ----

Currently <Add> requests for already existing calendar items are detected by the SyncEvolution backends. This has several drawbacks:
1. engine ID tracking may get confused
2. data does not get merged (backends don't have code for it)

See "[SyncEvolution] UID matching during add<->add conflict".

Lukas has a solution for point 1 and suggested an approach for point 2.



---- Additional Comments From patrick.ohly@intel.com 2011-10-26 13:37:43 +0000 ----

commit 739920c59e914ae077170c244d5d14cbf29630bd
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Fri Sep 30 18:27:50 2011 +0200

    testing: improved tests for add<->add conflicts (BMC #22783)
    
    When avoiding conflicting properties with merge=lines, items are
    completely replaced as originally expected. This allows testing the
    "server avoids unnecessary updates" aspect of add<->add conflict
    resolution.
    
    With an up-to-date libsynthesis (age comparison fixed, COMPARESCRIPT()
    fixed, suppress unneeded local and remote updates, fix statistics in
    server mode) these tests pass in server (local sync/CalDAV) and
    client mode (with SyncEvolution as server).
    
    Thus BMC #22783 is almost resolved, except for the open question
    whether merge=lines is desirable in this case.



---- Additional Comments From patrick.ohly@intel.com 2011-10-26 14:09:17 +0000 ----

*** https://bugs.meego.com/show_bug.cgi?id=22669 has been marked as a duplicate of this bug. ***



---- Additional Comments From patrick.ohly@intel.com 2012-03-13 10:09:38 +0000 ----

Almost done. See 409 mail thread(s) and commits.

Last open: detect whether storages really support full UID semantic, express that in the CTCap and adapt the engine's logic accordingly (= remove hard-coded "local sync == use UID" hack).



---- Additional Comments From patrick.ohly@intel.com 2012-05-09 11:41:27 +0000 ----

(In reply to comment #3)
> Almost done. See 409 mail thread(s) and commits.
> 
> Last open: detect whether storages really support full UID semantic, express
> that in the CTCap and adapt the engine's logic accordingly (= remove hard-coded
> "local sync == use UID" hack).         

Merged into master branches for 1.3:

commit 314f0736381fa1300bf52bfc5388e61e06083e30
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Thu Apr 26 14:27:22 2012 +0200

    local + remote sync: negotiate UID support via SyncCap (BMC #22783)
    
    This uses the new libsynthesis support for adding and checking entries
    in the SyncCap to detect per datastore whether UID/RECURRENCE-ID are
    truly globally unique and thus can be used to finding pairs. The
    presence of the property alone is no guarantee for that.
    
    Previously this kind of pairing was enabled only for local sync, which
    was a hack which didn't work for local backends which didn't support
    UID (for example, Maemo 5 calendar). It also didn't work for mixtures
    of datastores with and without that kind of support.
    
    "1122583000" was randomly chosen as pseudo sync mode. It is a number
    because strings confuse Funambol. Note that SYNCMODESUPPORTED() only
    works inside the compare script.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

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