On Di, 2011-04-12 at 13:37 +0200, Patrick Ohly wrote:
> On Mo, 2011-04-11 at 22:06 +0100, Frederik Elwert wrote:
> > As far as I understand, I’d normally need backend-to-backend sync
> > (Evolution → file). IIRC, that’s not yet implemented.
>
> It's implemented in 1.1.99.3. Here are some untested instructions:
>
> Configure the file backend which will store the vCards:
>
> dir=<absolute path to vcard dir>
> mkdir -p $dir
> syncevolution --configure \
> backend=file \
> database=file://$dir \
> databaseFormat=text/x-vcard \
> @gigaset addressbook
>
> Configure one-way synchronization from default system address book:
>
> syncevolution --configure \
> syncURL=local://@gigaset \
> peerIsClient=1 \
> sync=one-way-from-server \
> gigaset addressbook
>
> Run a sync:
>
> syncevolution gigaset
Frederik tried it and found some issues:
1. uri had to be set in "gigaset" addressbook. Fixed in current
code such that the source name is used as fallback.
2. Errors were not propagated, making debugging a bit harder.
Fixed.
3. A "source-config" peer in the "@gigaset" was required for local
sync. This requirement was originally introduced for
CalDAV/CardDAV because they need the syncURL for the web server,
but even there username/password from the main config can be
enough. So now "source-config" can be created (to set a
different loglevel, for example) but doesn't have to be.
4. A password issue prevented running in syncevo-dbus-server.
I wasn't able to reproduce the last issue. After fixing the first three
points, synchronization succeeded for me.
Frederik, I'll tag and compile 1.1.99.4 now. Let's retest with that.
Oh, and here's a much simpler way of achieving what you want to do ;-)
Sorry, should have thought of that earlier:
rm -rf $dir
mkdir $dir
syncevolution --export $dir @default addressbook
In contrast to true file syncing, it is limited to a full dump on each
call. I still appreciate that you brought up and tried local syncing!
--
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
