Hi Patrick,
On Feb 4, 2010, at 22:16 , Patrick Ohly wrote:
On Di, 2010-02-02 at 11:23 +, Lukas Zeller wrote:
We could check at syncagent.cpp:1171 if the abort reason status is
zero (i.e. ABORTDATASTORE(0) called), and if so behave differently,
i.e. just muting that datastore, but leave
On Fr, 2010-02-05 at 13:28 +, Lukas Zeller wrote:
[server progress events]
How urgent is it in an overall perspective?
I think we can affort to release SyncEvolution 1.0 in March/April
without it, althought it would be good to have.
[explanation why not aborting the session with the first
Hello Patrick,
On Jan 29, 2010, at 19:49 , Patrick Ohly wrote:
Another peculiarity: on the server, after calling ABORTDATASTORE(),
'ReadSyncSet' is done and items are read from the database as part of
'GetItems'. On the client, only 'ReadSyncSet' is done. Server log below.
Shouldn't the
Hello Patrick,
On Jan 26, 2010, at 17:38 , Patrick Ohly wrote:
As I might have mentioned before, in SyncEvolution we try to prevent
unwanted slow syncs to give the user the chance to choose some other way
of recovery (refresh sync, restore from backup):
On Mi, 2010-01-27 at 16:44 +, Lukas Zeller wrote:
What about datastoreinitscript or maybe initscript? These are
called before user data is accessed the first time, which would be
early enough to stop the whole thing if needed, but late enough to be
sure the sync mode is known. BTW: I
Hello!
As I might have mentioned before, in SyncEvolution we try to prevent
unwanted slow syncs to give the user the chance to choose some other way
of recovery (refresh sync, restore from backup):
http://bugzilla.moblin.org/show_bug.cgi?id=2416
My current solution only partly works in a SyncML
