3:13 p.m.
On Do, 2012-01-05 at 22:35 +0100, Justus-bulk(a)Piater.name wrote:
Patrick Ohly <patrick.ohly(a)intel.com> wrote on Thu, 05 Jan 2012
19:59:35
+0100:
>> - There appears to be no way to sync memos and todos using this setup.
>> Both are apparently stored inside /home/user/.calendar/db on the N9,
>> along with the calendar data, but from inspecting the source code of
>> this Harmattan syncevolution build it appears that these cannot
>> currently be sync'ed because this has simply not yet been implemented.
>
> True. If a developer with access to Harmattan is sufficiently motivated,
> then implementing that support won't be hard.
This was my impression. Getting these sync'ed as well would really make
my day. I can probably do it myself, but I cannot currently consecrate
significant time to it, and I am a stranger to the sync/evolution code.
Perhaps this summer. Unless someone else picks up this thread in the
meantime, would you work with me through this?
Of course.
> Second, is SyncEvolution creating automatic backups as part of
each sync
> session? Have a look at ~/.cache/syncevolution/<session> and look for
> addressbook.before/after. This feature can be disabled by setting both
> dumpData=0 and printChanges=0.
Yes, they are both there, containing 1062 VCARDs each.
What are the risks and implications of disabling this feature? Nothing
more or less than loss of PIM data if a sync goes horribly wrong?
Yes, exactly that.
printChanges is useful for detecting undesired changes and/or to keep
informed about updates. When not watching the output it can be safely
turned off. printChanges uses the same data dumps as dumpData.
dumpData controls whether the automatic backups are still done when not
needed for printChanges.
My evolution DBs on the laptop as well as the PIM DBs on the N9 are
backed up by my routine rsync backups. Can't Evolution be restored from
those backups if need be? Do I need to take the export route? If the
issue is merely one of avoiding races between backup reads and
simultaneous writes, then I can handle that.
If you have other backups, then you don't need SyncEvolution's builtin
backup mechanism. It's there and enabled by default because many people
don't have that, or don't backup frequently enough.
> Second, if merely exporting the data is slow, can you measure
that
> separately? Try
> time syncevolution --export /dev/null "your config name" addressbook
/home/user $ time syncevolution --export /dev/null client-for-laptop addressbook
real 4m 17.97s
user 4m 4.85s
sys 0m 2.35s
So this is it! Export before + export after = almost the entire time of
the sync! This also presumably explains why the sync appears to sit
idle for minutes after displaying "[INFO] addressbook: normal sync done
successfully".
I should add an INFO message for the data dumps. You are not the first
to wonder what SyncEvolution is doing.
It should also be possible to optimize the dumping of the entire
database. Right now, detecting changes and data dumps take different
code paths (Intentionally! A bug in change detection should not break
the backups) and happen to read one item at a time where batch
operations would be more efficient.
>> Thus, I am interested in trying out the N9's built-in
sync facilities
>> instead of the custom Harmattan syncevolution client,
>
> I understand you frustration,
I indeed moved quite close to the limits of my patience, and I feared
that I did not quite succeed in hiding it :-/
No worries, I found your email quite helpful.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.