Ability to Prune Page History & Set History Limits

Is your feature request related to a problem? Please describe.
The entire history of a page is remembered for each pages currently. This is a good feature for many people. Myself and I guess a lot others would also like the ability to instead limit the history to say the last week / last month / last N days / last 100 entries. This would help one in reducing the amount of storage used and will also help to declutter the data in Anytype.

Describe the solution you’d like
A global setting which can be changed to the number of days of history to store for each pages / Last N number of history to store / unlimited history. This should also delete the old images / icons used in the history when the history is removed.

Additional context
Page wise option would be great but seems like an overkill.

18 Likes

:clap:t2:

Sounds like obvious need for an Offline first data storage software.

1 Like

One thing I’ve observed about Anytype’s Version History page is that it seems to keep changes on an extremely granular basis, even going down to the individual word that’s been typed. While keeping these extremely granular version history logs are important for the “Control+Z” functionality, we probably don’t need this amount of granularity for changes that were made months or years ago.

Therefore, in addition to creating a limit for the amount of time version history is kept, perhaps, Anytype can automatically reduce the granularity of old history entries in order to save storage by only keeping the top level entry and deleting the sub-entries (seen in the version history view), rather than for every edit that’s been made. This should allow users to go back and restore the document to previous states, while still saving on storage by reducing the amount of states that are saved.

However, I do have to question how much impact version history, especially for text-based documents has on disk usage, as pure text shouldn’t take up that much space. Perhaps there is another underlying issue, not the revision history, that is causing problems around excessive storage usage?

4 Likes

True, this is also one reason for increased storage since not only the word is getting stored, meta data for that version such as the name, version number etc, are getting stored for each version entries which adds up to the large storage usage in the long run

It will not be an issue during the initial few months or years, but if one wants to use it for several years, unnecessary version history of all pages adds up to a considerable amount of disk storage.

By purge, I mean not only the page contents, but also the display pictures and older cover images which are not needed anymore.

I’d also be happy if other media files linked to the page is removed as far as it is the only place it is referenced, but that is debatable

2 Likes

Perhaps make a system where granularity decays the further back it goes.

For example, keep full granularity for the past couple of days. Paragraph level granularity for past week… etc. For changes done a year or more ago, it’s enough to keep page-level changes.

I’m sure it’s much (much) more complicated than that… But just a thought!

6 Likes