As part of the SyncEvolution 1.3 release preparations I did another full
test run this weekend. The good news first, I did not encounter the
"unexpected update" problem ;-)
But I noticed a regression in the testMerge test. That test checks how
the server behaves when client A and B cause an update conflict on the
server (= server has updated item from client A, then client B sends an
update in the sync where it is supposed to receive that updated data).
That test passed with Memotoo when testing SyncEvolution 1.2.1:
Now it failed as follows:
Client A sends updated contact with X-AIM added:
In the next session, the conflict occurs because client B sends an
update without X-AIM and some other field added:
The server seems to merge or overwrite the data on the server; it does
not send any data back to client B (go up one level in the link above to
see the full sync log and/or all other messages). In the 1.2.1 time
frame, Memotoo did send back an updated contact to client B in this
sync. Currently that seems to be broken.
What happens now is that in the next sync, when client A checks whether
anything has changed on the server, it is sent an updated contact with
the X-AIM field:
Now client A and client B are out of sync: client A has the contact with
X-AIM, client B doesn't.
The test accepts all kinds of conflict resolutions (duplicate items,
server wins, client wins), but it does not accept that the clients and
server get out of sync.
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.