On Mo, 2010-11-15 at 16:50 +0000, Patrick Ohly wrote:
> Now that I had that sorted out, I was running into another configuration
> issue: <slowsyncstrategy>duplicate</slowsyncstrategy> is set in the
> syncserv_sample_config.xml and SyncEvolution copied that. Therefore the
> engine ended up trying to duplicate events despite a UID match. This is
> not possible in the backend, which will always overwrite the existing
> event. So what I need in this case is "newer-wins" with "server-wins" or
> "client-wins" as fallback instead of "duplicate" - such a setting does
> not exist, does it?
After some more thinking I came to the conclusion that the fallback is
not needed for my iCalendar 2.0 case: because UID/RECURRENCE-ID will
always find pairs (if they exist) and LAST-MODIFIED is always there,
there will always be a "newer" item, so the "duplicate" fallback will
never trigger.
> Finally, remember that I had intentionally created differences in the
> SUMMARY of my two events. My expectation was that this difference would
> be resolved during syncing.
[...]
> Note that I made another change for my iCalendar 2.0 case: all fields
> have compare="never", only UID/RECURRENCE-ID has compare="always". Could
> that have an effect on merging once pairs are found? After looking at
> the code it seems so. compareWith() returns that the items are identical
> enough, despite the change in SUMMARY.
Yes, that was it. I had the idea of introducing a new "compare" level
between "never" and "conflict" to mark fields which are relevant for the
user (and thus changes must be stored), without using them to find pairs
(which levels >= "conflict" would do).
It turned out that Lukas already was ahead of me, as usual ;-) The new
level already exists, although in this case the purpose was a bit
different:
commit d96d05611cf7d35459927328e18b7f0f0a74571e
Author: Lukas Zeller <l...@synthesis.ch>
Date: Tue Aug 24 17:41:53 2010 +0200
engine: added new compare mode for fields: "scripted"
These are NOT included in standard comparisons, so the
comparison can be done in a script, but they are
considered relevant otherwise, in particular these
are included when calculating CRC for change detection.
I'm happy to report that using compare="scripted" solves the "SUMMARY
not updated" problem. Solved for me.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
