On 25.09.2014, at 08:43, Patrick Ohly wrote:
> [...]
> Would this "save state" include resetting the sync anchor?
No.
> I can't think
> of any other way how the server could avoid duplicates, because it
> cannot know whether the client has added the items and if so, under
> which ID... except t
On Wed, 2014-09-24 at 21:14 +0200, Lukas Zeller wrote:
> Hi Patrick,
>
> On 24.09.2014, at 17:33, Patrick Ohly wrote:
>
> > Let me pick your brain for a second... :-)
>
> It has gotten a bit rusty as far as sync is concerned. But I'll try :-)
>
> > When SyncEvolution runs a local sync (i.e. bo
Hi Patrick,
On 24.09.2014, at 17:33, Patrick Ohly wrote:
> Let me pick your brain for a second... :-)
It has gotten a bit rusty as far as sync is concerned. But I'll try :-)
> When SyncEvolution runs a local sync (i.e. both client and server are
> provided by SyncEvolution) and the sync gets a
Hello Lukas!
Let me pick your brain for a second... :-)
When SyncEvolution runs a local sync (i.e. both client and server are
provided by SyncEvolution) and the sync gets aborted (= STEPCMD_ABORT is
passed to SessionStep()), I noticed that the next sync starts again as
if nothing happened.
For e
