Hi everyone,
When editing in realtime the auto-save can possibly create a lot of document revisions (with partial changes). This makes it harder to work with the document history. There is pagination, but (until we move to live data) you can’t filter / search for a specific revision so you have to go through all the auto-saved revisions. To overcome this we could implement a way to group (collapse) revisions coming from realtime editing, BUT:
- it doesn’t seem easy to do
- and I’m not convinced that all those auto-saved revisions have long-term value (especially when the auto-save interval is very short)
With this in mind, I’m wondering if it’s not better to simply squash the auto-saved revisions, when possible. The realtime editing session could keep track of (and synchronize)
- the initial revision (when the editing session starts)
- and all the revisions authored from that editing session
With this we can determine if a squash is possible or not. As long as there is no revision created outside the editing session we should be able to squash. If the document is saved outside the editing session we could still do a partial squash, by squashing only the auto-saved revisions since that “outside” revision.
But what do I mean by squash? I’m thinking we could:
- collect the contributors from all the revisions to be squashed
- determine the contributor with the least script access right among those collected; if there are more, prefer the one from a more recent revision; if there are still more, chose at random?
- collect the change summaries from all the revisions to be squashed (ignoring duplicates)
- delete the revisions to be squashed
- create a new revision with:
- original author: the user that triggered the squash
- effective author: the contributor with the least script access right
- collected contributors (see Change attribution when editing in realtime )
- content submitted by the save request
- aggregated change summary
On the UI side, I imagine there could be 3 ways a user could leave the editing session:
- without triggering a squash, simply returning to view mode; this would be the default behavior when there are other users remaining in the editing session
- with a silent / automatic squash (no question asked), when you are the last one leaving the editing session, if a squash is possible, and it makes sense (i.e. there are at least 2 auto-saved revision to squash); this behavior could be turned off with a configuration
- with an explicit squash (again when possible), where the user can modify the aggregated change summary and chose between a minor / major version
WDYT? Do you see any problem with deleting document revisions (from the top of the document history) and replacing them with an “aggregated” (squashed) revision? Are there any security implications I’ve missed?
Thanks,
Marius
5 posts - 4 participants