http://bugzilla.moblin.org/show_bug.cgi?id=2425 --- Comment #5 from pohly <patrick.ohly(a)intel.com&gt; 2010-03-04 02:38:37 PST --- (In reply to comment #4) Only in some very constructed situation, and one which is not currently covered by any of our tests. Here's where the two anchors make a difference: 1. client and server in sync 2. item added on server 3. client and server sync 4. suspend after sending that new item to client 5. a second item added on server 5.1 resume => send changes since step 4 5.2 two-way sync instead of resume, using anchors from step 1 => send changes since step 1 Our server fails in 5.2, because it will always only send changes since the last sync (step 4 in this example). The relevance of this is debatable. It depends on clients actually being able to roll back to a previous state. Our own client can't do that, so it would have to do a slow sync in 5.2 instead of resuming. More important is support for blobs. Large items that are not transferred completely at the time of the suspend are stored as a blob. -- 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.