If conflict happens , I’d suggest to show the conflict details to help user decide the following operations.
I’d really like this feature too. Not sure if there’s currently the capability to show a clean
diff, though a nice temporary measure could be the option to write a message when you “Upload to AnkiWeb”. Displaying the last message on this prompt would be helpful enough
Yeah, a little overview like the one file managers show for file conflicts would be really nice:
Maybe with a little comparison of the collections (date, size) as well?
This is not simple I’m afraid. Conflicts are triggered by an ‘unmergeable’ flag that doesn’t identify the change that has triggered it. File size can be misleading, as disk space is not freed immediately after items are deleted. And modification times can be updated by simple actions like clicking on a deck. I have some ideas for how things can be improved, but it’s probably going to require a new sync algorithm.
Perhaps a simple solution to avoid conflict is to sync right away if updated, AnkiDroid does have the feature but doesn’t the Anki Desktop.
As a few ideas:
- if, for some reason, it’s impossible in any ways to synchronize changes “nicely”, it would be better to simply sync with deltas, just like most sync tools do (i.e. rsync). You don’t have to write it yourself, as there are quite a few rust libraries available for any use. This is better than what I suspect to be the current method, which is simply send the whole database (whenever I change a single notetype, the synchronization requires sending MBs…).
- SQL actually already implements to some extent declarative updates, meaning that it’s easy to keep track of database updates with git-like tools, which already include both delta-pushes and detailed diff reports, which can be shown to the user to help him chose.
- An other advantage of git-like handling is that it can handle two “conflicting” versions, and, most of the time, figure out the best thing to do, except when the same object has been modified in both versions in different ways, so the user could chose, instead of which version to keep, which modification of each version to be kept in the merge.