It is difficult to explain this by email. I'm afraid we do not
Forget I said about the way "Evolution -> Memotoo" because it is not it.
You said "I also noticed that only calendar items were affected. The
test passed for contacts - shouldn't it also fail for those?". I think
it is an exception in Memotoo but to find it you must run again your test.
Can you try again your tests with "sc-api-A" and "sc-pim-B" ?
Le 16/03/2011 10:21, Patrick Ohly a écrit :
On Mi, 2011-03-16 at 08:44 +0000, Thomas Pequet wrote:
>> Is this "SyncEvolution -> Memotoo" setting the default for new
> The default setting is "both ways"
> "sc-pim-B" is actually "Evolution -> Memotoo" for calendar, I
> comes during the diffrents test you do before this test...
I don't understand. How is that setting related to the earlier tests?
Perhaps I don't understand the meaning of this setting. My understanding
so far was that it is a server-side setting which somehow overrides the
sync mode requested by the client. Is that correct? If not, what does
that setting really do?
What you say above makes it sounds like the setting is taken from the
client's sync mode. If so, why have that setting at all if the client
can change it at any time?
Anyway, the setting seems to be irrelevant. It seems I cannot get the
server to apply an update to calendar data with a Replace command at
all. How can we debug this?
> Le 06/03/2011 16:52, Patrick Ohly a écrit :
>> On Sa, 2011-03-05 at 17:06 +0000, Thomas Pequet wrote:
>>> Thanks Patrick
>>> I have seen that the device
>>> "syncevolution-3b3d8d41-71db-477b-b91a-08600a31cd93" (the 2nd)
>>> only "Evolution -> Memotoo" in Memotoo:
>> Each test session starts with random device IDs, as if the user had
>> started using MemoToo for the first time.
>> Does it mean that all users who want to download data from Memotoo need
>> to reconfigure their account?
>> Does it apply only to *updates* during a two-way sync? *New* items seem
>> to get transferred (but that might be during a slow resp.
>> refresh-from-server sync).
>> I also noticed that only calendar items were affected. The test passed
>> for contacts - shouldn't it also fail for those?
>> I'll change the testing to use fixed device IDs now, and try again. Hmm,
>> didn't work. I used the "syncevolution" account, device IDs
>> sc-pim-B. The test fails, but the web interface shows "both ways" for
>> these two devices and calendar events.
>> The synchronization history for "sc-api-A" shows:
>> phone meeting SyncEvolution » Memotoo : Add 2011-03-06 - 16:35:42 (G.M.T.
>> There should also be a later entry for *updating* that item. To me it
>> looks like the server ignores the Replace command from the first client
>> (sc-api-A in this case):
>> The data on the server definitely is the older item, not the update.