12:10 p.m.
On Thu, 2011-09-15 at 15:40 +0200, Lukas Zeller wrote:
Hi Patrick,
On Sep 12, 2011, at 20:33 , Patrick Ohly wrote:
> The only remaining question is: should the merge take full advantage of
> the age information available in this case ("newer wins") or merge data
> on a per-property basis for those which support it (multi-line +
> merge=lines)?
What it exactly *should* do is probably depending on the reason why
the plugin asks for merging, and would need to tweak the merge
options / merge scripts such that it makes sense.
What it does so far is only a merge, with fixed roles: the incoming
item is the "winning" side, the DB item is the "loosing" side,
without
checking age information. Without a merge script, what happens is what
TMultiFieldItem::standardMergeWith() does, which is
based on the "merge" option set in the field list.
I think that makes sense, except for the "fixed roles" - more on that
below.
> What I see is right now is that for SUMMARY, the most recent
value is
> used (good!).
It's just the value coming from the remote, most recent or not.
Then it happened to work as expected accidentally, or I wasn't looking
closely enough.
Because "SUMMARY" has no field-level merge option, which
means that
the winning side overwrites the loosing side.
Of course, in the "most recently made known to the recipient", the
incoming item is the most recent one by definition, but not
necessarily in terms of when the user last edited it.
I think in this particular case, iCalendar 2.0 with UID, doing an age
comparison by default would be the right choice. I have implemented
that, see attached patch. Does that look right?
Note that it also avoids local DB updates which were found to be
unnecessary because the local side wasn't changed.
This does not yet address the situation where the remote side also
wasn't changed. A redundant Replace command will be sent in that case.
Do you have a hint for me how this can be avoided? In the server case,
is it as simple as avoiding the SendItemAsServer(augmentedItemP) call?
Would it make sense to add an option to configure 509-merge run in
one
of "DB wins", "incomin wins", "newer wins" modes?
SyncEvolution doesn't need it at the moment, if you agree that the age
comparison should be used by default.
> In the case of iCalendar 2.0 I wonder whether merge=lines is
needed.
> For modify/modify conflicts perhaps, but not so much for add/add
> conflicts. Thoughts?
If you want to differentiate these cases, I'd say we'll need a
MERGEREASON() script function so the script can act differently
depending on why the merge is initiated. So far I see the following
different reasons: slowsync non-perfect match, syncml update conflict,
DB update conflict, DB add conflict.
I'm inclined to rather remove the merge=lines and thus keep properties
from the winning side in all cases.
Except... what if a dumb phone truncates a property and then a slow sync
is done? Will the default merge mode preserve the longer property or
truncate if the version on the phone happens to be considered "winning"?
--
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.