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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
