Le 13/04/2012 17:16, Patrick Ohly a écrit :
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-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
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-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.
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-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.
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-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/
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.
Ok I think I have corrected this :)
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
