Re: [SyncEvolution] Memotoo refresh + empty data

On Do, 2011-08-18 at 15:22 +0200, Thomas Pequet wrote: > If I remember that we said... When you do a refresh-from-client and > there is no data in Memotoo, Memotoo ask a slow sync ... Why force a slow sync in this case? A refresh-from-client has the exact same effect, whereas forcing a slow sync confuses the client because it cannot tell whether something went wrong or the server is simply empty. The "prevent unexpected slow sync" feature in SyncEvolution doesn't work with Memotoo because of this. If I remember correctly, the logic rather was "if the server is empty, always do a slow sync, regardless of the mode requested by the client". The justification was that if the user wipes out all data on the server via the web UI, he expects to get all data from the device instead of also removing the data on the device in the next two-way sync. I still don't buy that argument because there are better ways of achieving it (when resetting the server, reset sync anchors), but that's just my preference. Anyway, I reran all tests for contacts and some of them fail with unexpected behavior by the server: http://syncev.meego.com/2011-08-19-07-20_testing_memotoo/head-testing-amd... testDeleteAllRefresh: 1. four items in sync on client and server 2. client deletes all items, asks for refresh-from-client => no items transferred 3. slow sync to verify => four items recreated on client The server seems to have ignored the request to delete its data before syncing in step 2. Is that intentional?

testRefreshFromClientSync: succeeds because the client doesn't really check the semantic of the operation, only the sync mode. testRefreshFromClientSemantic: exactly the same as testDeleteAllRefresh - I wonder whether the test should be modified to test something else, like replacing the server data with some other local data. testOneWayFromServer: 1. client A, B and server empty 2. client A add one item, sends to server 3. client B adds one item locally, does one-way-from-server

Instead of the one-way-from-server sync, the last step ends up doing a slow sync because the server sends an empty sync anchor. Then the client sends its one item (which it wouldn't normally do in a one-way-from-server sync) and later the server asks the client to delete that item (which again wasn't meant to happen). The expected outcome would have been that the one new item on the server gets added to client B, while the new item on client B remains there (not deleted, not sent to server). The client asks for a 202 sync in its Alert (http://syncev.meego.com/2011-08-19-07-20_testing_memotoo/head-testing-amd...).

Why does the server accept that and then send an empty anchor? The previous sync with client B is here: http://syncev.meego.com/2011-08-19-07-20_testing_memotoo/head-testing-amd...