On Fri, 2011-09-30 at 12:10 +0200, Patrick Ohly wrote:
> > In the case of iCalendar 2.0 I wonder whether merge=lines
> > 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
> 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
is done? Will the default merge mode preserve the longer property or
truncate if the version on the phone happens to be considered
I'm still curious about that.
Note that the previous age comparison patch had the -1/+1 logic
reversed. It worked correctly in my tests because the COMPARESCRIPT()
macro always returned 1 although it should have returned -1. Later it
failed for the inverse test.
Fix for that and updated patch attached.
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.