Reverting to a document version creates a new one

[almereyda]

When rolling back a document to a previously stored state, a new revision at the current date and time is created.

For rolling back in time, where we also want to roll back edit times, and have this represented in document lists, could we imagine a sort of "hack" that creates a new "version forked" / "version restored" commit, and have the modification timestamp list the previous version?

Maybe the thread where one was thinking out loud on Twitter about timestamps at https://twitter.com/tommoor/status/1467930411925794816 and before has something to add here?

atime is for Last data access timestamp.
mtime is for Last data modification timestamp.
ctime is for Last file status change timestamp.

• atime is last time opened &/ written
• mtime is last time document state changed
• ctime is last time document metadata changed

I wonder where this differentiation could lead next. Which other cases could profit from this kind of timestamping?

• Real-time documents, which haven't persisted to server, yet?
• As such intermediary versions (mtime), which lie between global sync (ctime)?

• Email invites, which changed state (from non-existent to pending; ctime), eventually resent (mtime) and then opened (atime).

• Share links, which were created, updated, and used. ref. Track last accessed time for share links #2046

https://superuser.com/a/729349/236480

Then there's also btime, which we get from the first version of a document.

[almereyda]

I'm completely thinking this from the way how Federated Wiki references "forks" of "previous revisions" between documents. The action itself is visually distinct from mere edits.

Grey flags are restorations of a previous version, and coloured flags are forks of revisions from another domain (via CORS). This way we keep a distributed revision log, where each revision only knows one parent.