Version history

Route: Library → History · any token's history icon · Settings → History

Pro, cloud libraries only. Local mode has no version history — there is no server to keep one, and undo plus the export bundle already cover it.

What is kept

Every save of a cloud library is archived automatically, server-side. Nothing has to be remembered or pressed: the archive happens as part of the save, so a version exists for every state the library has been in.

This runs on the free plan too. You cannot read history without Pro, but it is being recorded from your first save — so upgrading shows the past that was already kept, rather than starting a timeline from the day you upgraded.

Three ways to look

The timeline (Library → History) lists every version, newest first, with who saved it and roughly what it touched. Select one to see how far it is from the library as it stands, then restore it.

A single item's history — the small clock icon beside a token — answers "who changed this". With the drawer open, Ctrl+Z (⌘Z on a Mac) steps that item back through its recorded states and Ctrl+Shift+Z steps it forward. Only that item changes; everything else in the library stays where it is. Outside the drawer those shortcuts keep their usual meaning.

The full log (Settings → History) is every recorded change in one table, filterable by date, by person and by what kind of thing changed.

Restoring

Restoring is soft. The state you are leaving is archived first, so a restore can itself be undone by restoring the version it created. That is why the confirmation says nothing is lost — it is a description of what happens, not reassurance.

A restore is an ordinary save, so if a colleague saved while you were deciding, you get the same "someone else saved" warning as any other edit. That dialog now offers a third option: open the history and look before choosing.

Two versions cannot be restored straight away, and both say so before you confirm:

• One written by a newer version of Tostada than you are running. Update first — loading a shape this version cannot see would drop the parts it does not understand and then save that loss back.
• One from before the current colour model, which resets colours to the starter palette rather than loading them half-migrated. A partly migrated colour system looks like a working one until somebody opens dark mode.

"Details not recorded"

A row that says this is not a row where nothing changed. The per-change summary is worked out by the app at save time, and a version can simply not carry one — one saved before summaries existed, or one where the comparison did not complete. The version itself is whole and restores normally; only the description of what it changed is missing.

Rows that genuinely changed nothing say No changes. The two are kept separate on purpose.

How long history is kept

Versions are thinned as they age, so history does not grow without bound:

The five most recent versions of a library are never removed, whatever their age — a library nobody has touched for a year still has a history to open.

These numbers are provisional and will be tuned once real usage says what they should be. If a retention change would affect you, it will be said before it happens rather than discovered.

What this is not

• Not a merge tool. Two people saving at once is still last-write-wins, made visible. History is how you recover from it, not how you avoid it.
• Not a value-by-value diff. A version says which items changed, not what each one changed from and to. For that comparison, see tracking drift.
• Not branching. There are no named checkpoints and no "start from this version" — history is a line, not a tree.