On Fr, 2012-01-06 at 08:13 +0100, Patrick Ohly wrote:
> > > 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 should add an INFO message for the data dumps. You are not the first
> to wonder what SyncEvolution is doing. 

Are the following INFO messages informative enough?

        [INFO] eds_contact: starting normal sync, two-way (peer is server)
        [INFO] creating complete data backup before sync (enabled with dumpData 
and needed for printChanges)
        Local data changes to be applied during synchronization:
        *** eds_contact ***
        no changes
        
        [INFO] eds_contact: started
        [INFO] eds_contact: normal sync done successfully
        [INFO] creating complete data backup after sync (enabled with dumpData 
and needed for printChanges)
        
        Synchronization successful.
        
This is the default case with dumpData=1 printChanges=1. The explanation
in brackets changes depending on these settings.
Only dumpData set:
        [INFO] creating complete data backup before sync (because it was 
enabled with dumpData)
Only printChanges set:
        [INFO] creating complete data backup before sync (needed for 
printChanges)

It's not exactly a fix for https://bugs.meego.com/show_bug.cgi?id=24619
but as it is minor, I'll add that together with the fix to a 1.2.2
update (if that ever happens, not sure yet).

-- 
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

Reply via email to