[FR] Edit history

[emmggi]

Description

I suggest document work space to have edit history. It should keep track of changes we do in our documents. This would make most sense for the document work space. I don't see this being useful for calendar, grid or kanban.

Most important use case for this is when a user deletes a piece of information that will be important in the future.

Impact

All users.

Additional Context

1. Should have a list of edits in a dialog/side bar.
2. Title of the list item should have its date and time. Subtitle could have how many blocks were changed or how many characters are different.
3. Clicking on an edit should show difference side by side or inline, between state of the current document and the edit we clicked on.
4. We should be able to search history for keywords.

I suggest making the data for edits compact. Maybe just persist blocks that were changed in the database, not to create huge DB files, but I'll leave this to the more knowledgeable.

[lalomartins]

To add my 2¥ to an issue that for me is a dealbreaker:

A risk is that storing every revision ever might bloat the storage needs and get unwieldy over time. The most common fix for that is to simply limit the retention, but that then makes the feature no longer suit all use cases; for design documents, for example, it's important to have a history going back to the first draft so we can trace how the design evolved.

What I find the best solution is to have a retention window (maybe a week) within which we keep all revisions, and then when passing that, keeping only key revisions.

The two ways I know about for deciding what is a key revision are:

• Explicit, or named revisions, or commits. Google Docs does this. Someone can manually go in the history and tag a revision with a name so it won't get deleted.
• Automatic, session-based. If the time between revision A and the next one B is more than a certain limit, say 6 hours, then A gets saved permanently.

With a session-based approach, there could even be 2 layers of retention. For example, once per day we could remove revisions more than a day older, where there is a newer revision less than 30 minutes later; and then once a month we could do the same but with a window of 12 hours.

For maximum flexibility, both approaches could be combined too, at the cost of bloating the UX. That is, revisions to preserve are picked automatically, but explicitly named revisions are taken out of the algorithm entirely and never removed.

Okay, that may have ended up being 4 or 5¥ 😹 I hope it's useful.