Re: [SyncEvolution] Synchronization between two Linux-based computers
On Do, 2011-01-20 at 08:55 +0000, Giuseppe Gerace wrote:
Hi at all,
I have a problem. I am trying to synchronize a pre-registered client
with the server. The version of SyncEvolution involved is the "1.0".
1.1.1 is recommended for running as SyncML server (both HTTP and direct
sync with phones).
I am using Evolution backends. The client synchronizes itself with
server by SyncUI. After the synchronization, there are two problems:
1) The data changes were not displayed into Evolution
2) In syncevo-dbus-server output, there are some unrecognizable prints
My question is: what types of data are supported by SyncEvolution? In
" /home/peppe/.evolution/addressbook/local/system " there is only a
".db" file.
Contacts, events, tasks, notes, stored in Evolution and plain files. The
latter is the root cause of your issue.
You configured the server like this:
syncevolution --configure \
--source-property type=file:text/vcard:3.0 \
--source-property evolutionsource=file:///home/peppe/.evolution/addressbook/local/system
\
${peer} addressbook
This means that you are writing inside Evolution's data path, but you
are not using the Evolution contacts backend. Instead you create one
file per contact inside the ".../system" directory, which Evolution
knows nothing about and thus ignores.
If you have suggestions how the "server HOWTO" should be rewritten to
cover both the "headless server without Evolution" case as well as your
"desktop to desktop" sync, then please feel free to propose something -
documentation depends on such feedback to become better.
You need to configure each source to use the normal types (addressbook,
calendar, tasks, notes). Unset evolutionsource to use the default
Evolution databases; "syncevolution" without parameters will show you
what it would (or could) use.
I don't know what you mean with "unrecognizable prints" in the output.
if that still is an issue, please provide more information about that.
--
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.