3:40 p.m.
Hi Patrick,
On Sep 12, 2011, at 20:33 , Patrick Ohly wrote:
[...]
So next is DB_Conflict = 409. The merge+update itself works. It seemed
to go down a similar code path as 207, but didn't crash.
Makes sense now according to the bug you found with deleting augmentedItemP. With 409,
augmentedItemP is really owned at this point and must be deleted. Only with 207 the delete
removed an item that still belonged to the to-be-sent items list.
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.
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. 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.
Would it make sense to add an option to configure 509-merge run in one of "DB
wins", "incomin wins", "newer wins" modes?
DESCRIPTION and LOCATION get concatenated, with older
value first. That's not bad, I just wonder.
merge="lines" treats lines in the texts as subrecords, and concatenates the
loosing side to the winning side but omitting "subrecords" that already exist in
the winning side.
For example:
Winning Loosing Result
foo now foo
bar merge bar
now foo now
merge
This usually renders useful results with short notes-style fields (which are unlikely to
have the same line (subrecord) more than once). For more sophisticated cases, a
mergescript would be needed.
The SyncEvolution config is:
<field name="DMODIFIED" type="timestamp"
compare="never" age="yes"/>
[...]
<field name="SUMMARY" type="multiline"
compare="always"/>
<field name="DESCRIPTION" type="multiline"
compare="slowsync" merge="lines"/>
<field name="LOCATION" type="multiline"
compare="slowsync" merge="lines"/>
So I guess the engine works as expected.
Looks like :-)
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.
Best Regards,
Lukas