Re: [SyncEvolution] New version of Memotoo server

On Mi, 2012-04-11 at 11:43 +0200, Thomas Pequet wrote: > Le 10/04/2012 17:30, Patrick Ohly a écrit : >> On Fri, 2012-03-30 at 20:06 +0200, Thomas Pequet wrote: >> 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... >> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... > Ok now it is corrected :) Confirmed. >> MoreData support is better, but not fully okay yet. >>> ----------------------------- >>> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... >>> 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... >> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... >>> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... >>> It is suspicious that the affected item was sent using MoreData. > This problem is because I use a "trim" function when I get the data... > So if I receive with "space" at the end or at the begin, it is removed ... > Now it will be better. Confirmed. >> ----------------------------- >>> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... >>> 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... >>> 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... >>> 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... >>> 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... >>> 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. > I will have difficult to correct this ... Will the updated item on the server be sent in the next sync? Otherwise client and server remain permanently out of sync. >> ----------------------------- >>> 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... >>> Populate server: >> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... >>> Slow sync: >> http://syncev.meego.com/2012-04-10-08-05_testing_memotoo/testing-amd64/23... > May be it come from the previous ID problem. > Can you try again ? No, still fails. I reran the test manually, so logs are not public yet.