Dear Patrick, Thank you for your exhaustive answer.
Patrick Ohly <[email protected]> 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 _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
