Reverting Changes

A revert undoes one specific change — and only that change. Where a restore rewinds a file wholesale to a point in time, a revert is surgical: it takes the properties that one revision touched and puts just those back to their prior values, leaving every later, unrelated change in place.

When to reach for it

Suppose a file was renamed on Monday and its content edited on Wednesday. It's Friday and you've decided Monday's rename was a mistake:

• Restoring to Sunday would undo the rename and Wednesday's edit.
• Reverting Monday's rename undoes only the name — Wednesday's content edit survives untouched.

Reverting

In Flashback, right-click the offending event and choose Revert this change. From the terminal, pass the revision ID from poly file history:

# Find the change
poly file history //Home/docs/report.pdf

# Undo it
poly file revert //Home/docs/report.pdf --at 018f3c2a

How it works

Poly diffs the file's state immediately before the revision against its state at the revision — that's the exact set of properties the change touched. It then applies the before values of just those properties on top of the current file. Details that fall out of this design:

• Later changes are safe. Reverting a rename never disturbs a subsequent content edit, tag, or move — different properties, different clusters.
• It's idempotent. Reverting a change that's already been undone is a no-op, not an error.
• It's history, too. A revert is recorded as a new change, attributable and itself revertible.
• Creations can't be reverted. There is no "before" state for a file's creation — to make a file go away, archive it instead (poly rm).

Conflicts

A conflicting edit — one that lost a same-time race against another writer — sits in history like any other event. Reverting works on those too, and Open at revision / Copy file at revision let you recover the losing content without changing the current file at all.