Restore points

Twenty saved versions of a project, taken when the files actually change - what triggers one, and how to go back.

View as .md

If you have overwritten or deleted something and want it back, restore points are how. A project keeps up to 20 of them: complete copies of every file, that you can go back to.

What triggers one#

A restore point is taken when the project's files are actually different from the last one.

That also means a long debugging session where you change one line at a time can consume them quickly - each edit that gets run is a distinct working set.

Going back#

Restoring replaces the current files with that version's. The project keeps working; you have simply moved back to how it was.

It is the answer to two situations the file tree cannot help with:

  • You deleted a file you needed. Deleting is immediate and there is no recycle bin, but an earlier restore point still has it.
  • A change made things worse and undo has gone too far back, or you have closed the tab since.

What they are not#

  • Not a version control system. No branches, no messages, no diff between arbitrary points. If you want history you can reason about, push to GitHub - see pushing to GitHub.
  • Not a backup of anything outside the project. Linked Canvas boards are not included; they live in Canvas and have their own history.

Run history is a different list#

Run history keeps the last 50 runs - what you ran and what it printed. It records outputs, not files. Restore points hold the files; run history holds the results.

Was this page helpful?

Last checked against the product on . Behaviour changes are listed in the changelog.