2 p.m.
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...
(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.