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.