New conflict resolution modes #127
Comments
Complete noob suggestion: "a wins, drop b's collision-data" Use a string like "vdirsyncer-conflict:" prefixing the note data for the user to use for searching during a cleanup session. |
This is already done with |
Yes I was just including them for completeness. I assumed you were defining a collision as a conflict at the field level - I think Annemarie's tool I just discussed with you has a "merge" choice - On Thu, Feb 12, 2015 at 3:21 PM, Markus Unterwaditzer <
|
I'm currently doing this on a per-item basis, so I can avoid parsing the items in normal situations. Perhaps per-field conflict resolution could be implemented on top of it. I don't know how that tool lools like. |
Yes, an intra-item parse and merging when no fields in common are in "That tool" meaning Annamarie's? She really is very approachable, friendly On Fri, Feb 13, 2015 at 1:22 AM, Markus Unterwaditzer <
|
That'd be ideal, although I currently don't know how to do that in a reliable
Yeah. I didn't mean to describe ContactSync in such a degoratory tone.
I want to take a closer look at it before doing anything else. There are a |
If we have new conflict resolution methods, comparing the item's revision (vCard) and sequence number(iCal) would be my first choice, since software that edits the entries should be incrementing these. Why the IETF didn't pick the same field name on both specs amazes me. |
|
The RFC is pretty ambiguous, quote:
So what exactly is a 'significant' revision? Also what happens if I change a parameter and change it back after saving that event, but without it being uploaded to the server? Should the SEQUENCE be incremented once or twice? With all that said, I'd still enable the "later sequence wins" strategy as I believe it would work good enough in practice. |
I can't imagine a case where the sequence number is useful in the case of Or it only shows which side increases SEQUENCE more aggressively, which is an
At least in the case of vdirsyncer the item is uploaded anyway, and I think On Tue, Jul 14, 2015 at 02:18:48AM -0700, Christian Geier wrote:
|
The program that edits the event doesn't do anything dav-related, so it would increment the revision every time there's a change.
You're perfectly right. Silly oversight on my part.
How does DavDroid know it has been modified? Is it an event editor as well as syncer? Or just by timestamp? |
As far as I understand it the dmfs tasks provider for android has a bool dirty flag for each task, which gets set to true by the dmfs Tasks app if the task is edited. When syncing, DavDroid uploads those tasks and resets the flag. Vdirsyncer uses mtime from the filesystem for that: Our "flag" is comparing the current mtime with a previously saved value. So both vdirsyncer and DavDroid are (I think) not caring if a change has been reverted: The flag/mtime did change and that's what matters. It just occured to me we have the same problem with using REVISION as with any other property: If one editor doesn't support it, it might make vdirsyncer biased towards the other side. So maybe we should only use this if both REVISION values changed so we know both clients support it - but then we'd have to keep track of old values. I think I'm slowly tending to be against that resolution mode because of this. Basically for almost any mode where we inspect the item content, I think we need the item content from the previous sync as well, just like we store etags at the moment. Then we could do all the fancy things git does, i.e. merging items per property. But this would require ALL CONTENT FROM ALL ITEMS, which is an insane amount of data to fetch on first sync. |
Uhm, aren't we fetching all this anyway? |
Ah yes, indeed. Then the only disadvantage is storing all the content once again on disk. I'm not sure if that's worth it... |
Also the status file will get immensively big, so we have to change its format to avoid writing the whole file on each sync. |
Eg, if Note that this does not violate the vdir spec, but the new file should be ignored by any vdir-complaint tool. What I'm still unsure is how to tell vdirsyncer "hey, I'm merged this manually, keep the local version". Changing the settings might result in accidentally overwriting another, new conflicting entry. |
I rather had something interactive in mind:
This kind of conflict resolution is much more easily discoverable, and I would make it a default. With your suggestion I see the problem that the user might not grep the vdir for conflict files (like I myself never look for Also it's not implementable in a generic way since it assumes that one storage of the sync pair is the filesystem storage. |
I really like that proposal, but it needs to deal with being run non-interactively (since I run it via cron and get the output via email, and I'm sure I'm not the only one doing so). Maybe an extra flag can trigger You can scrub my previous suggestion completely in favour of this one. :D |
One probably should be able to configure a command other than vimdiff. In your case you'd probably have a script that copies one file into the other and sends you a mail that it performed conflict resolution or something. Or it copies both files into a backup dir... Would you be willing to implement this @hobarrera? :) |
Yes of course, I'd assumed we both had that in mind
I'd rather the conflict resolution do nothing if not running interactively. Maybe don't-run manually if we're not currently on a tty or something?
Sure, looks like a fun (and useful) challenge. :) |
You could just exit with a non-zero exit code from your script for the same effect. This presumably already happens if you invoke
Great. Feel free to ask any questions about vdirsyncer's internals or things like that. |
- Using `info.idents` as new status, this saves a few operations where no storage actions have to be taken, but the status has to be updated. - Rename StorageSyncer to _StorageInfo and make it a private API again. - Ability to pass custom functions for conflict resolution. This part is a preparation for #127.
- Using `info.idents` as new status, this saves a few operations where no storage actions have to be taken, but the status has to be updated. - Rename StorageSyncer to _StorageInfo and make it a private API again. - Ability to pass custom functions for conflict resolution. This part is a preparation for #127.
- Using `info.idents` as new status, this saves a few operations where no storage actions have to be taken, but the status has to be updated. - Rename StorageSyncer to _StorageInfo and make it a private API again. - Ability to pass custom functions for conflict resolution. This part is a preparation for #127.
I think the current options are not very useful.
None
is a sane default, but nearly useless in practice.* wins
, on the other hand, might lead to data-loss.keep both
would delete the old item from both sides and upload both versions as new items. This is not very easy to implement as we would have to change or remove the item's UID. We already use icalendar for item-changing operations (e.g. splitting bigVCALENDAR
files) but that library is not very vcard-aware and since #70 i am kinda scared to further involve icalendar in vdirsyncer's operations.Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: