Features
Todo

Version Control

What's the scenario?

Example 1: You are working on a document and someone accidently deletes a section they thought wasn't necessary but you know it is. Currently, you're unable to see who has made edits to a page, when they last made edits, and have no way to revert those changes.

Example 2: You are independently drafting a working proposal for a client. This is your second draft and upon presenting it to the client, there are a number of changes they preferred in the earlier proposal. Unless you saved the earlier document elsewhere, you have no way to reverse your changes.

While it could be cool to have block-level version control, I think object level version control is sufficient in all but extreme edge cases.

What's the goal?

  • Allow users (particularly in a shared space) to revert to earlier changes within an object.
  • Allow users to see who last made changes and when those changes were made to an object.
  • Allow queryable system properties for last changed by and time last changed

Who is this for?

Every user on Anytwo. Initially it'd likely be most useful for shared spaces, but could also be useful for a user working on an independent project. This would be particularly useful in the Anytwo Assembly Space so newly onboarded tester can get a sense of what's changed.

2 Comments

Sign in to comment

AL
Alex Lins (Bao)·about 1 hour ago

Thanks for the detailed scenario — version history and revert are clearly missing from shared workflows. A couple of clarifications would help us scope this right:

  1. When you revert to an earlier version, should it replace the current state entirely, or would you want to see a diff first to pick which changes to undo? (The "second draft vs. client's preferred version" example suggests you might want to cherry-pick, not just rollback wholesale.)
  2. For "last changed by" — does that need to track every single edit (keystroke-level), or is object-level snapshots (one entry per save/publish cycle) granular enough? The proposal mentions object-level is sufficient — just want to confirm that matches the use case.
  3. In a shared space, how far back should history go — forever, or some practical window (e.g., last 30 days, last 50 versions)?
JP
Jesse Perl
Jesse Perl·about 1 hour ago
  1. I think just reverting the entire state would be more user friendly. I know some of us power users would love to see diff and manually pick the changes, but that might be a lot to implement on a first pass, and might be better suited to folks using github as a backup.
  2. Object-level snapshots of one entry per save or after 120 seconds of no keyboard use would be great.

  3. I'd love if the space owner could be given the option choosing:

    1. no version control
    2. last 10 versions
    3. 30 days
    4. forever

This would allow each space to be better tailored to specific needs.