2-way sync logic

DAVx⁵
Log in to reply
  • A

    Hi,
    I just made a test on how the 2-way-synch works. I made changes on the server and in davdroid (on the phone). What I found is following:

    1. When I change 2 independent dates (eg. subject, location) of a calender entry, the version on the server wins.
    2. When I change an calendar entry on one side and delete it on the other, the version in davdroid wins

    a. I’m wondering why 2. is?
    b. I’d like to find the 2-way synch logic explained somewhere
    c. I’d like to see that changes in different fields could be merged.
    d. I’d like to configure which side (davdroid or server) wins

    Regards,
    Martin

    0
  • rfc2822
    developer 

    When I change 2 independent dates (eg. subject, location) of a calender entry, the version on the server wins.

    Correct.

    When I change an calendar entry on one side and delete it on the other, the version in davdroid wins

    If you delete the entry on the device and change it on the server, the next time DAVdroid syncs it:

    1. tries to delete the entry (but only the exact entry it has stored, marked by its ETag) from the server, which will do nothing becaues the entry has been changed,
    2. syncs all entries from the server to the device, resulting in the entry that was changed on the server to be downloaded.
      “server wins”

    If you delete the entry on the server and change it on your device, the next time DAVdroid syncs it:

    1. tries to upload the contact, which will succeed,
    2. syncs all entries from the service to the device, including the newly uploaded.
      “DAVdroid wins”

    a. I’m wondering why 2. is?

    DAVdroid never overwrites data on the server.

    b. I’d like to find the 2-way synch logic explained somewhere

    https://github.com/rfc2822/davdroid/blob/master/src/at/bitfire/davdroid/syncadapter/SyncManager.java, see method “synchronize”

    c. I’d like to see that changes in different fields could be merged.

    iCalendars and VCards are whole entities. Merging would be very cumbersome and error-prone and may not be possible without user interaction. It may also result in data loss because the wrong version may be overwritten. Do you actively use a revision control system like svn or git? The same difficulties apply here.

    d. I’d like to configure which side (davdroid or server) wins

    I think it makes sense that the server always wins because there may not only be one client. If the client would win, there could be a situation where client A uploads its contact, then the next time client B uploads its contact, then A again, then B… see CalDAV RFC: Creating Calendar Object Resources for the proper use of HTTP precondition headers which imply a “server always wins” strategy.

    But if you want to change it, feel free to download the code and change it for you. 🙂

    0
  • A

    Thanks for the extensive answer. But it seems I found a bug then. DAVDroid deletes events on the server even if they were modified.

    I’m using

    • DAVDroid 0.5.9
    • Cyanogenmod 10.2.1 (Android 4.3.1)
    • SOGo 2.2.0 (Ubuntu Server)

    To reproduce do the following:

    1. Add an event to the server with
      • Title: Breakfast
      • Location: Kitchen
    2. Sync
    3. On the server: Change Location to Balkony
    4. In DAVDroid: Delete event
    5. Sync

    The event gets deleted on the server. Might also be that SOGo does something wrong. But from your statement I derive that this shouldn’t happen.

    0
  • rfc2822
    developer

    @napfi You’re right, this shouldn’t happen. I have investigated and found a bug that caused the events to be deleted at the second attempt (because the dirty flag was not removed after the first, unsuccessful [because it changed on server-side] attempt to delete the event).

    It should now work.

    0
  • rfc2822
    developer

    Also, one of my statements above is wrong:

    If you delete the entry on the server and change it on your device, the next time DAVdroid syncs it:

    • tries to upload the contact, which will succeed,
    • syncs all entries from the service to the device, including the newly uploaded. “DAVdroid wins”

    Correct is (I have just tested it):

    If you delete the entry on the server and change it on your device, the next time DAVdroid syncs it:

    • tries to upload the contact, replacing exactly the old version that is referenced by its ETag, which will not succeed becaues this precondition fails (because the event is gone),
    • syncs all entries from the service to the device, resulting in the locally-changed event to be deleted. “Server wins”

    So, the server always wins, which is the desired strategy.

    0

Similar topics