On Do, 2011-02-10 at 15:19 +0000, Frederik Elwert wrote: > Am Donnerstag, den 10.02.2011, 13:38 +0100 schrieb Patrick Ohly: > > On Do, 2011-02-10 at 08:38 +0100, Patrick Ohly wrote: > > > On Mi, 2011-02-09 at 19:29 +0000, Frederik Elwert wrote: > > > > Hi Patrick, > > > > > > > > Am Dienstag, den 08.02.2011, 08:55 +0100 schrieb Patrick Ohly: > > > > > Downgrading is still possible. If you plan to do that, make a copy of > > > > > ~/.config/syncevolution and restore that later. You'll run into slow > > > > > syncs; resolve these with an explicit slow sync or refresh syncs. > > > > > > > > You mean, slow syncs are expected when downgrading? But a normal upgrade > > > > should not trigger a slow sync? > > > > > > > > I ran into a slow sync after migration with the new version, and I don’t > > > > know if that was to be expected. The commandline gives me: > > > > > > > > [INFO] memo: inactive > > > > [INFO] calendar: resuming slow sync, two-way > > > > [INFO] todo: resuming slow sync, two-way > > > > [INFO] addressbook: starting slow sync, two-way > > > > [INFO] calendar: resumed slow sync done unsuccessfully > > > > [ERROR] unexpected slow sync (local, status 22000) > > > > [INFO] todo: resumed slow sync done unsuccessfully > > > > [ERROR] unexpected slow sync (local, status 22000) > > > > [INFO] addressbook: slow sync done unsuccessfully > > > > [ERROR] local, status 10415 > > > > [ERROR] error code from Synthesis engine local, status 10415 > > > > > > A slow sync after a downgrade from 1.1.99.2 -> 1.1.1 is expected, but > > > not for the upgrade. I need to test this. > > > > In my test, no slow sync was needed after the 1.1.1 -> 1.1.99.2 > > migration. > > > > I find it a bit strange that "resuming slow sync" is mentioned above. > > That sounds a bit like the previous sync before the migration hadn't > > completed normally. In that case all bets are off. I don't expect the > > more recent version to be able to resume an older sync, but I don't know > > for sure.
Frederik helped me debug this by sending log files privately. It turns out that he had an inconsistent config (type = "calendar" set for addressbook in the @default context, "addressbook" in the "memotoo" peer), which worked for syncing but then broke during the migration because the migration code took the backend selection from the broken context config. I've added a workaround for this which copies the peer's backend selection into the migrated config. There's still the possibility that different peers had different backends selected inside the same context, but this is less unlikely and thus I haven't added any special code for it. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
