I realize this is far out of scope for Bear 2.0, but I wanted to put it out there for future consideration. I had never proposed this for Bear 1 because I figured it would be far too complicated in a database framework like Bear since there’s no way to tie in to Time Machine or any other OS hooks. But then I read how Reflect is doing this (in their case, it’s an electron app using Google’s Firestore for note storage) - and I thought it was quite elegant: Reflect note history.
Having the ability to retain edits over time - for some notes - can be quite helpful. Thanks for the consideration.
note history is something we had in mind when building Bear 2 tech stack, but we require a few more steps before achieving history and will see the light after 2.0 release. What we had in mind is not too different from Reflect’s. Note history comes with a problem with attachments and disc occupation which is particularly concerning on iPhones and iPads. We currently have not found a good solution for this issue.
Version control is something I highly desire and I am excited to hear that it may come sooner or later.
I am just not sure if we understand the same by that. For me version control means to browse through manually saved versions of a note. If at all an automatic saving of versions (f.e. in intervalls) is implementedi i hope that it can be disabled
My main feedback having used the Bear v2 beta is that note version history is a killer missing feature. On iOS especially I sometimes unintentionally make changes to notes or accidentally delete notes and it is incredibly frustrating to try and figure out how to get back to a known good state. Google docs is another good example of version history done right.
Keeping a close eye on this thread, if we can be of any help with specific testing @trix180 do let us know
Honestly @trix180 - even if the iOS apps only had access to the latest live version but the desktop app stored a version history this would be 95% of the solution. I’m currently reliant on time machine backups and trying to restore a note this way is painful.
How about manual snapshots for specific notes then? Considering all the baggage that comes with implicit versioning I think this would be a more pragmatic alternative and would naturally solve the conundrum with storage cost by giving the choice to the user.
Agreed. I backup all notes every day, but I’m still overly paranoid that I can lose a day of work on some note if I accidentally remove something and close the app.
There’s workaround I found on reddit: duplicate note & archive it right away (available in context menu with a single click). Not perfect but better than nothing…
In the following thread automatic backups was discussed:
As mentioned in the thread the ulysses app has a good backup sheme and a good ui from where you can restore single notes or the whole backup.
When it comes to version control i wouldn’t confuse it with backups. A version control has a different approach. While backups are made automatically and in a speciifed time rhythm for the purpose of saving and restoring notes in case of a loss, the version control should serve another purpose: you are manually saving diiferent but equivalent notes, means: versions are not made automatically for backups, but manually for working with different versions with the aim at some point to choose the best one or - why not - to keep several of them.
(I know that in semantical sense the terms backup and version control can be interchangeable. My point was to show that two different features are meant when speaking about versions. And what i’ve described above how i would like to have a version control seems a reasonable feature. However, an automatic backup like discussed in the linked thread is highly desired too)
Well, you can call manual snapshots a .bear file you save for each version of each note but it doesn’t sound like a user-friendly idea having to remember yourself to make versions. The storage problem is a huge problem (99% of it concerns attachments) and we can’t really avoid it, we can just mitigate it with communication and UI/UX.
You can take a look at how e.g. Git manages it: it only stores deltas between versions, so if large file wasn’t changed, no additional information would be saved.
Though, as already noted, it would be fine if Bear manages versions just for the text information. In my opinion that’s much more valuable piece of data (because we often have attachments stored in yet another application, but not in case of text notes). And it also consumes much less space.
There are techniques more sophisticated than deltas for solving versioning, CRDT is possibly “the one”.
We do get most people will be just fine with the support for text but is hard communicating versioning doesn’t work for attachments. On the other hand, if we offer something called “note versioning” users’ assumption is it does work for everything inside the note, attachments included. This makes me think we should handle attachments too to provide a better feature and not deceive expectations.
Fully agree. Attachments need to be included in version control. I used some app that didn’t sync attachment versions but didn’t communicate it properly and I lost work because of that.
Chiming in rather late here, but I would love note history! I often find myself copying over old snippets of text into a “junkyard” note and then later archiving that note. It’s a very manual process
