Le 10/04/2012 17:30, Patrick Ohly a écrit :
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
Ok now it is corrected :)
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.
-----------------------------
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 ...
-----------------------------
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 ?
------------------------------
Thanks Patrick !
I think I will pass this version in production.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
