On Mon, 2017-05-01 at 17:15 +0200, Vincent Lambert wrote: > Le 28/04/2017 à 11:36, Patrick Ohly a écrit : > > On Fri, 2017-04-28 at 10:18 +0100, Graham Cobb wrote: > > > On 28/04/17 10:05, Patrick Ohly wrote: > > > > On Fri, 2017-04-28 at 10:31 +0200, Vincent wrote: > > > > > Could you tell me more about synccompare? > > > > In the syncevolution.org packages, it is under /usr/bin/synccompare. > > > > It's a perl script that takes two database dumps and compares them, > > > > similar to a diff between text files. > > > I find it to be of variable usefulness. It is great when it works, but > > > in my experience it scales horribly. > > I just use it on a laptop and it works for me, but I agree that it's > > mostly a hack originating in the automated testing. There's even a bug > > open for rewriting it... > > > > > I think I always see "comparison was impossible" with refreshes. I > > > assumed that is because the databases are deleted or something (although > > > thinking about it further I am not sure that is a reasonable expectation). > > There should be "before" and "after" dumps also for refreshes, so this > > has to be something else. > > > > So what is the goal of this command?
It's purely informational. It's not needed for the sync to work. > I deleted the two related to my configuration, restarted to clear the > sessions and then added again my notes taken from there > http://influence-pc.fr/03-07-2015-synchroniser-ses-contacts-et-calendrier-dubuntu-phone-via-owncloud-cosy-cloud > (was working from past 2 years) so just after the first "sync slow" here is > what I can see: So was this a slow sync or a refresh-from-remote sync? > Changes applied during synchronization: > +---------------|-----------------------|-----------------------|-CON-+ > | | @default | @owncloud | FLI > | > | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS > | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | contacts | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 > | > | slow, 0 KB sent by client, 44 KB received > | > | 140 item(s) matched > | > | item(s) in database backup: 140 before sync, 140 after it > | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | start Mon May 1 16:47:48 2017, duration 0:13min > | > | synchronization completed successfully > | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > > Data modified @default during synchronization: > *** @default/contacts *** > Comparison was impossible. > > > Even if I delete the config, the backup database still contain > entries! Not the *backup* database. Your local *system* database still has these 140 contacts. Removing the SyncEvolution configuration does not clean that database, because it exists independently from SyncEvolution. So for a slow sync, the behavior quoted above is as expected. A "--sync refresh-from-remote" would tell SyncEvolution to erase the local contacts before the sync, so all of them then should show up as "new" on the local side. -- 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] https://lists.syncevolution.org/mailman/listinfo/syncevolution
