[SyncEvolution] Memotoo event slow sync + RECURRENCE-ID ("testTwinning") (was: Re: Memotoo: tasks regression?)

Hello Thomas! The task regression is indeed resolved. On Wed, 2011-10-19 at 16:03 +0200, Thomas Pequet wrote: IMHO that needs further work, see my other email. Here's another problem: http://syncev.meego.com/2011-10-20-13-22_all/head-testing-amd64/20-memoto... The situation is the following: * client has sent all event test cases * a slow sync is forced to check how well the server matches the client's data with its own ("twinning") * with Memotoo, some items get rejected: [2011-10-21 05:06:08.943] WARNING: RECEIVED NON-OK STATUS 500 for command 'Add' (outgoing MsgID=2, CmdID=5) * [2011-10-21 05:06:08.943] - SourceRef (localID) = '13684708-rid20080413T090000Z' These are: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.27//EN BEGIN:VEVENT LAST-MODIFIED:20111021T050528Z DTSTAMP:20111021T050605Z UID:13684708 CLASS:PUBLIC SUMMARY:Recurring 2: Modified DESCRIPTION:second instance modified\, single detached recurrence DTSTART:20080413T090000Z RECURRENCE-ID:20080413T090000Z DTEND:20080413T093000Z END:VEVENT END:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.27//EN BEGIN:VEVENT LAST-MODIFIED:20111021T050527Z DTSTAMP:20111021T050605Z UID:13684712 CLASS:PUBLIC SUMMARY:Recurring: Modified DESCRIPTION:second instance modified DTSTART:20080413T090000Z RECURRENCE-ID:20080413T090000Z DTEND:20080413T093000Z END:VEVENT END:VCALENDAR BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.27//EN BEGIN:VEVENT LAST-MODIFIED:20111021T050527Z DTSTAMP:20111021T050605Z UID:13684712 CLASS:PUBLIC SUMMARY:Recurring: Modified II DESCRIPTION:third instance modified\, different time DTSTART:20080413T100000Z RECURRENCE-ID:20080413T100000Z DTEND:20080413T103000Z END:VEVENT END:VCALENDAR These are exactly the VEVENTs which have a RECURRENCE-ID. -- 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.