Dear Patrick,
Thank you for your exhaustive answer.
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?
10 minutes is indeed very slow. Are you interested in investigating
this
further?
Yes, I am!
First, does the SyncEvolution binary or the synccompare perl script
consume the CPU time? You said that it is be binary, but I want to be
sure. Invoking the perl script is controlled by printChanges.
It is the syncevolution binary.
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?
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.
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 had trouble getting all of my data onto the N9 because of
timeouts
> and other issues. I was completely unable to transfer my 13 years
> worth of appointments ("D-Bus peer has disconnected" after many
> minutes and transferring 212/5955 appointments), and had to resort to
> moving the entire past into an unsync'ed calendar on the laptop.
That hints towards timeouts somewhere, but without detailed logs from
both sides it is hard to tell where.
No big issue for me. But now that I've learned how to set the timeouts
(for the addressbook sync), I may give this another shot one day. I'll
report here if I learn something interesting along the way.
> 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 :-/ But let it be heard that I
am extremely grateful for your work and that of all those other FOSS
developers that allow me to live in near-complete software freedom. I
wish my professional constraints allowed me to give back more to the
community.
but keep in mind that at least the SyncEvolution still has an active
maintainer (Ove) and an active upstream project
(
syncevolution.org). The built-in sync is pretty much a dead end. It's
calendar sync is considerably limited (only does vCalendar, for
example).
Good points. I'll stick with SyncEvolution for now.
Best,
Justus