On Fr, 2011-07-29 at 11:25 +0200, Jelle de Jong wrote:
So after many months I was excited to try syncevolution with caldav
and
carddav support today.
I executed my configuration commands as earlier posted on this mailing-list.
Those are obsolete and no longer work in 1.1.99.5. Please follow the
WebDAV instructions in the README:
http://syncevolution.org/documentation/syncevolution-usage
If DAViCal has a URL for your user ("principal"), then you can use that
as common syncURL for both CalDAV and CardDAV. I think it supports that.
Please see the bellow pastebin URL that contains the details
(versions,
configuration, and syncevolution commands)
http://paste.debian.net/124460/
----------------------------------------------
Doing a slow synchronization may lead to duplicated items or
lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status davical-caldav addressbook calendar
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-server|refresh-from-client] davical-caldav
addressbook calendar
-----------------------------------------------
This is something that'll show up even with the current instructions.
It's intentional, you need to make a choice as explained above.
Note the warning in the README:
Warning: in local sync, the sync config side acts as server.
Therefore the from-server variants (one-way-from-server,
refresh-from-server) transfer data from the sync config into the
target config. The from-client variants transfer in the other
direction, even if the target config happens to access data on a
remote server.
If you want to avoid dealing with this, configure the target-config with
"preventSlowSync=0".
--
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.