On Fri, 2012-03-30 at 20:06 +0200, Thomas Pequet wrote: > Le 30/03/2012 15:47, Patrick Ohly a écrit : > > On Fri, 2012-03-30 at 15:16 +0200, Thomas Pequet wrote: > >> Le 30/03/2012 11:31, Patrick Ohly a écrit : > >>> On Fri, 2012-03-30 at 09:32 +0200, Thomas Pequet wrote: > >>>> Le 30/03/2012 09:02, Patrick Ohly a écrit : > >>>>> The testManyItems for events failed with something that looks like an > >>>>> internal error in EDS and/or SyncEvolution. It is unclear why the > >>>>> following item was asked for in the first place. I'll investigate: > >>>>> > >>>>> [ERROR 00:00:53] error code from SyncEvolution object not found > >>>>> (remote, status 404): eds_event: retrieving item: > >>>>> 008-1234567890!@#$%^-rid > >>>>> http://syncev.meego.com/latest/testing-amd64/23-memotoo/Client_Sync_eds_event_testManyItems.log.html > >>>> I have corrected the MoreData bug, > >>> Confirmed, that seems to work now (manual tested, still need to run the > >>> full suite again). > >>> > >>>> so may be it will be better for > >>>> testManyItems. > >>>> I think the problem code from Memotoo with the new version. Give me the > >>>> XML and I think I will see the problem > >>> It's indeed on the server side. The server seems to truncate the local > >>> ID at the& sign. > >>> > >>> <Add> command sent to server: > >>> http://syncev.meego.com/latest/testing-amd64/23-memotoo/Client_Sync_eds_event_testManyItems.send.client.A/syncevolution-log_trm002_003_outgoing.xml > >>> > >>> <Status> received back: > >>> http://syncev.meego.com/latest/testing-amd64/23-memotoo/Client_Sync_eds_event_testManyItems.send.client.A/syncevolution-log_trm002_004_incoming.xml > >>> > >>> I know, I am a nasty bugger for sending such tricky characters in the > >>> local ID, but these are the corner cases which have to be tested>:-> > >> You have right to want to test all case ! :) > >> Theses links do not work ... Can you send me the good link to see the XML ? > > > > Replace "/latest/" with "/2012-03-29-17-01_testing_memotoo/" and you'll > > find the files. > Ok thanks ! I have corrected the problem of "&" :) > You can send again the tests.
Sorry for the delay, I was away last week. A full test run today shows that ID problem still exists: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_event_testMerge.log.html http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_event_testOneWayFromRemote.log.html MoreData support is better, but not fully okay yet. ----------------------------- http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testItemsXML.log.html vCard data with lots of "> & > & > &..." looses a space at some point. Does not happen when using WBXML. XML message dumps are here (sending to Memotoo and retrieving again): http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testItemsXML.send.client.A/syncevolution-log_trm002_003_outgoing.xml http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testItemsXML.send.client.A/syncevolution-log_trm003_005_outgoing.xml http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testItemsXML.refresh.client.B/syncevolution-log_trm003_006_incoming.xml It is suspicious that the affected item was sent using MoreData. ----------------------------- http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testMerge.log.html In that log client A, client B and the server have the same item. Client A and client B both modify that item, then client A updates the server: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testMerge.update.client.A/ Then client B tries the same, leading to a conflict on the server: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testMerge.conflict.client.B/ The expectation is that the server somehow resolves that conflict. The tests shows that Memotoo merges the conflicting item data. After client B is done with the server, client A synchronizes again: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testMerge.refresh.client.A/ The expectation is that in that sync, client A is sent the data as it now exists in client B and the server. The server sends "John Doe" with a "X-AIM" property: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_contact_testMerge.refresh.client.A/syncevolution-log_trm003_006_incoming.xml But client B doesn't have that property. It seems to me that the server should have sent the merged item to client B in the "conflict" sync above, which it didn't do. ----------------------------- Finding twins during a slow sync fails for calendar events. Although client and server have exactly the same data, a duplicate item is created on the client: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_event_testSlowSyncSemantic.log.html Populate server: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_event_testSlowSyncSemantic.send.client.A/ Slow sync: http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23-memotoo/Client_Sync_eds_event_testSlowSyncSemantic.slow.client.A/ ------------------------------ -- Bye, Patrick Ohly -- [email protected] http://www.estamos.de/ _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
