Just wanted to add my two cents on this topic. But what I love about ankimobile is that I cannot in any way accidentally edit any of my notes (or at least not as easily as anki desktop). On desktop, I am always paranoid in the browser that one wrong click due to poor mouse coordination and I can significantly alter a note without being aware or being able to revert just that specific change without doing some sort of full scale backup restore. The most common thing I accidentally edit are tags since that can be done with just a mouse. But another one that causes me a lot of consternation is that with a mouse you can highlight a section of text and then drag it to another field box or place within the same field. In other words, an entire cut and paste with just the mouse. If there was some way to make edits impossible with just using the mouse I think that would be a feature positive. Just my two cents.
I was actually thinking of editing anki source code to include some sort of note version control system (like git) that tracks changes to note and allows specific note reverts. I think my coding skills are improving enough that I could pull it off. I was thinking of adding a new table to the database that is similar to the revlog table but which tracks content changes as events and then links (or foreign keys) back to the notes table. What do you guys think? If I invest time into this, you think it could be a feature you guys would consider merging into the source? Or do you think anki itself should avoid a feature like this (plugin, etc?).
I spent quite a while building this, and I’ve earmarked it as “finished”, although it doesn’t have enough users that I’m certain it’s stable.
You can try this if it is amenable to your collection (it doesn’t support cards in distinct decks, or extremely large media collections), but my advice to you is actually to just ignore this problem.
There are a lot of technical problems that arise while building or even just using a version control system for a program as complex as Anki with its database format. In the time I spent writing ki, I learned how to use Anki to get around the issues that originally made me want to build it. I do not even use ki anymore as it’s simply a source of unneeded complexity in my workflow.
Anki just makes like 50 copies of your collection as a backup mechanism by default, I think, spread over your editing history. Two years ago that seemed very crude to me, but now I have come to see it as elegant in the extreme. (Kudos @dae and friends!)
It is (comparatively) very simple to implement, very simple to understand, and makes it pretty damn hard to lose data, at the expense of a bit more manual work than something like git. To me that looks like an excellent tradeoff.
“New systems mean new problems.”
– Hermione Granger
Storing changes in the collection risks the collection size ballooning if frequent small edits are made, and would require changes to the sync protocol. I won’t say never, but it’s probably not going to happen in the near future I’m afraid.
omg! This is awesome! thank you so much! I will try it out.
Not that I think you should necessarily pursue this, but if you were going to, it probably wouldn’t be necessary to store all deltas. The last 10 or so would probably be sufficient for most use cases.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.