Module revert
Expand description
Undoing somebody else’s work: a contiguous run of changes, addressed by what it is rather than by where it sits on a local stack.
UndoLog only holds actions this process
handled — a peer’s change re-baselines without pushing — so “undo what
the agent just did” finds nothing there. A run is addressed instead by
content-addressed HistoryEntryId, so a peer that only ever received
those changes can undo them. The inverse is written forward through
write_patches, never cut out of the
graph, so the original keeps its author and the undo is itself undoable.
Not wholesale: inverting a splice deletes everything in the span,
including what somebody typed there afterwards. So a Slot written
since the run is left alone and reported in RevertOutcome::kept, and
a caller must consult RevertOutcome::is_complete before saying
“undone”.
Structs§
- Change
Run - A contiguous run of changes, addressed by its first and last change.
- Kept
Slot - A slot the revert declined to touch, and why.
- Revert
Outcome - What a revert did, and what it deliberately did not do.
Enums§
- Revert
Error - Why a run could not be addressed at all — distinct from “addressed it and
chose to keep some of it”, which is
RevertOutcome::kept. - Slot
- A place in the document a change wrote to, at the granularity where two writers collide.
Functions§
- latest_
run_ by - The contiguous run of changes authored by
actor_hex, ending at the document’s newest change by that actor. - plan_
revert - Work out what undoing
runwould do, without touching the document. - revert_
changes - Undo several changes, each on its own, into one open transaction:
changespairs each change with the actor hex whose work it is, newest first. Every revert is planned before any is written, because reading the history closes the open transaction, which would commit the first revert as a change of its own. - revert_
run - Undo a run of changes by writing its inverse forward into
doc. - run_
bounds - Both returned head sets are prefix frontiers of the document’s own causal
order, so they are valid arguments to
AutoCommit::diffand mean the same thing on every peer holding the same changes.