Merging

[LorenzHorvath]

Currently, an import always overwrites the cards in the existing deck. This can cause significant issues, especially when multiple people are working on the same deck simultaneously, leading to lost changes—a problem I have encountered frequently over the past few months.

This might be a naive suggestion, but isn't there a straightforward technical solution? We could export the last modified field of each card to the JSON file, compare the last modified timestamp of the note being imported to that of the existing note, and decide which one to keep based on that comparison.

Of course, we need to ensure that performance remains stable. I myself am currently dealing with around 6,000 cards in a single deck.

I would appreciate hearing your thoughts on this, especially considering that I'm not familiar with the intricacies of the CrowdAnki implementation.

[aplaice]

Thanks for raising this and for the suggestion! (It seems to be generally useful.)

My main worries regarding the idea (off-the-cuff, haven't thought too deeply):

1. Is Anki's timestamp reliable? (I vaguely remember the timestamp/modified on some of my cards totally not being the expected value — I think the issue was that just opening/browsing the note in the "Browser" would update the timestamp, but I haven't checked this recently)
2. (As you note) performance considerations. However, if we will only be doing this when importing (rather than exporting/snapshotting (and if I understand your suggestion correctly we will indeed only do so when importing)), it shouldn't be a major issue. (Obviously, this will have to be profiled.)
3. Aesthetic issues — it feels very slightly ugly. (For comparison, git for instance doesn't store dates in its tree objects, just file hashes; unfortunately, the exact contents of Anki notes (when including various metadata) is very Anki version dependent.) (Obviously not a dealbreaker, though.)
4. Dealing with note-level merges — i.e. when two users have updated the same note. There seem to be two cases here: a) the local user's update was more recent (we bring up a dialog?) or b) the remote user's was more recent (we overwrite the local user's changes).
5. Dealing with reversions. (Probably could just bump the timestamp.)

My preferred solution would be something more git-like in the sense of comparing with the most recent common ancestor, as it feels more generally flexible, but it's also far more complicated (it also doesn't directly help with, say, 4, (edit: it won't help deal with 4a (we still need a dialog etc.) but would catch 4b) though it would resolve spurious bumping of the timestamp).

@Stvad might have more refined thoughts as the creator! :)

---

(One partial alternative — just for data-loss — would be snapshotting before an import.)