http://bugzilla.moblin.org/show_bug.cgi?id=4457





--- Comment #5 from pohly <[email protected]>  2009-08-03 06:59:13 ---
(In reply to comment #4)
> retest with snapshot 20090730, we now get the correct sync results:
> 
> 1. create a recurrent eventA on server(schedulewoorld) with occurrence {A1, 
> A2,
> A3}, refresh them to client(Moblin netbook) through SyncEvolution
> ==> {A1, A2, A3} are shown in calendar on client ( client received 1 change )
> 
> 2. delete A1 on server, and sync in two-way
> ==> {A2, A3} on client, {A2, A3} on server
> 
> 3. delete {A2, A3} on server; and refresh A from client to server
> ==> {A2, A3} on server, and {A2, A3} on client ( client sent 2 changes )
> 
> 4. refresh A on server to another client(FC10)
> ==> {A2, A3} in evolution on fc9
> 
> Before verifying this bug, I got a small question about the statistics of
> occurrences. 
> 
> We could see that in step1, client received 1 change, while in step3, client
> sent 2 changes. seems that they are counted by different rules, with step1 by
> counting the entire(parent) recurrent event, and step3 by counting every
> instance(child)?

Each item should be counted once. Step 3 should send one VEVENT, so one change
should be counted.

Can you create a separate issue for this and attach a sysynclib_linux.html log
of step 3 to it?

-- 
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues

Reply via email to