On Thu, 2011-09-08 at 12:30 -0400, Ross Vandegrift wrote: > On Thu, 2011-09-08 at 09:17 +0200, Patrick Ohly wrote: > > On Mi, 2011-09-07 at 17:48 -0400, Ross Vandegrift wrote: > > Let me phrase the question differently: if the options for "--sync" aka > > "--source-property sync" had been named as follows, would that have > > avoided the problem? > > > > $ syncevolution --sync ? > > --sync > > Requests a certain synchronization mode when initiating a sync: > > two-way = only send/receive changes since last sync > > slow = exchange all items > > refresh-from-remote = discard all local items and replace with > > the items on the peer > > refresh-from-local = discard all items on the peer and replace > > with the local items > > one-way-from-remote = transmit changes from peer > > one-way-from-local = transmit local changes > > disabled (or none) = synchronization disabled > > > > refresh/one-way-from-server/client are also supported. Their use is > > discouraged because the direction of the data transfer depends > > on the role of the local side (can be server or client), which is > > not always obvious. > > > > When accepting a sync session in a SyncML server (HTTP server), only > > sources with sync != disabled are made available to the client, > > which chooses the final sync mode based on its own configuration. > > When accepting a sync session in a SyncML client (local sync with > > the server contacting SyncEvolution on a device), the sync mode > > specified in the client is typically overridden by the server. > > Yes, this explains the situation quite clearly - I think this is a clear > improvement.
Created https://bugs.meego.com/show_bug.cgi?id=23537 to track the proposal. It's too late for 1.2, so I made the warning about this problem a bit more prominent in the 1.2 README. -- 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
