Improved revision control related to posts and the numerous auxiliary benefits

[carike]

Imagine for a moment, the Gutenberg full-site editing capability is in full swing:

• How does a user restore defaults?
• How does a user easily undo actions?
• How does a user easily go back to a previous theme?
• If the user deletes a theme, how can all the associated custom post versions for that theme be deleted as well?

That (and more) could be easily achieved if posts revisions worked in a different way.
In the Gutenberg full-site editor example above, each theme could create a "branch" of revisions.
There would then be major and minor versions.
I propose that the default should be to keep all major versions (unless the user manually deletes them of course), as well as all minor versions since the last major version up to the current version.
This would allow for the user to "back space" in the full site editor, but in a way that is actually meaningful.

It has been suggested that a user could simply set the revisions constant.
However, particularly in an environment that encourages "tinkering" like the Gutenberg full site editor would be, it is entirely possible that a user could create a thousand revisions in a very short period of time.
Since there is no way to know which revision is which / search revisions, allowing users to "backspace" isn't meaningful.
Having "branches" would also allow plugin authors to create simple mechanisms to do A/B split testing on appearance (not content, that should still be possible).

Moreover, this has a huge implication on the size of the mySQL database, particularly in shared hosting environments and particularly when site content is exported and imported using the core Tools.

While it is not feasible to keep 35 trivial changes to the background colour, every semi-colon change to a Terms of Service may very well be crucial.
The core infrastructure should allow (whether inside core or via plugin) for different treatment of different post types in regards to revisions.

This ticket is related to https://core.trac.wordpress.org/ticket/21666, but is not a duplicate.

[carike]

Discussions in Slack:
​https://wordpress.slack.com/archives/C02QB2JS7/p1576159025020500 (link to thread).

"Because this is why every drag-and-drop page/theme editor on the market sucks.
The change-trail they create is horrifically designed+managed, and it's a performance nightmare.
And WP's database structure is designed for the complete opposite of this approach. ^
[...]
Not at all. We're saying that as WP gradually moves towards full site editing, the revisions system is too basic and too blunt to support many real-world use-cases, both technically and operationally."
- @jonoalderson

"You need to remember that a drag-and-drop site builder is mainly created for the type of audience who uses Microsoft Word - many will hit Save manually after very trivial changes."
- @carike

@williampatton may be able to assist quantifying the impact of revisions on performance.
William also made the awesome suggestion of considering an additional table, to limit the performance impact even further.
We also believe that a hook will allow for efficient exporting options.

[carike]

Link to the #core-editor meeting in Slack where this ticket was discussed:
​https://wordpress.slack.com/archives/C02QB2JS7/p1576679886104000