Hello Patrick, sorry for the late answer. I've been on a business in Germany last week and as usual, stuff has piled up in my inbox.
Digging though the case for a while, I suddenly realized that in client case the implProcessItem() method used is the one in binfileimplds.cpp and not the one in customimplds.cpp. However, we added the 409 merge trick in customimplds.cpp only - no wonder it "goes south" in the client case. I'll check if I can easily add the same functionality to binfileimpds. The reason why it is a separate method with seemingly duplicate functionality is that binfileimpl is integrated tightly with the binfile-based change log mechanism (even if you don't use it) - which makes the implementation differ quite a bit even if functionality provided is (i.e. in this case: *should be*) the same. Best Regards, Lukas PS: I'm almost trough with detangling my repositories such that I can now work exclusively with the opensource libsynthesis repo, which will help a lot keeping everything up-to-date there and integrate patches more quickly. As soon as the transition is complete, I'll also move the public libsynthesis repository to gitorious. On Dec 14, 2011, at 16:10 , Patrick Ohly wrote: > I've started to test SyncEvolution client <-> SyncEvolution server > automatically. The server is currently using the plain file backend and > thus cannot detect add<->add UID conflicts. > > In the test of that aspect I noticed the following problem: > * client and server both have a new item with UID=foo > * client sends an Add UID=foo to the server, which accepts the new > item, leading to a duplication on the server > * in the same session, the server sends his version of the UID=foo > item > * the client's backend detects the duplicate and returns 409 to > the engine > > Here's the detailed log: > > http://syncev.meego.com/2011-12-14-12-24_testing_syncevohttp/testing-amd64/15-syncevohttp/Client_Sync_eds_event_testAddBothSides.send-update.client.B/syncevolution-log.html > > > * [2011-12-14 12:48:53.896] InsertItemAsKey res=409 > * [2011-12-14 12:48:53.897] cannot create record in database > (sta=409) > * [2011-12-14 12:48:53.898] Database Error --> SyncML status 409 > * [2011-12-14 12:48:53.899] - Operation add failed with SyncML > status=409 > –[2011-12-14 12:48:53.900] End of 'Process_Item' [->top] [->enclosing] > * [2011-12-14 12:48:53.901] processSyncOpItem: Error while processing > item, status=409 > * [2011-12-14 12:48:53.902] Irregularity in execution of item, > status=409 > – > [2011-12-14 12:48:53.903] 'issue' - issuing command, > Cmd=Status [--][++] [->end] [->enclosing] > * [2011-12-14 12:48:53.903] Command 'Status': is 1-th counted cmd, > cmdsize(+tags needed to end msg)=38, available=149687 > (maxfree=260907, freeaftersend=260869, > notUsableBufferBytes()=111220) > * [2011-12-14 12:48:53.904] WARNING: Non-OK Status 409 returned to > remote! > > From there on it all goes south ;-) > > The next sync in my testing is an intentional slow sync. The server > still has the two items with the same UID, the client adds one, then > rejects the second => slow sync fails, test aborts. > > Lukas, can you remind me how this was meant to work? > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
