Skip to main content

Module revert

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§

ChangeRun
A contiguous run of changes, addressed by its first and last change.
KeptSlot
A slot the revert declined to touch, and why.
RevertOutcome
What a revert did, and what it deliberately did not do.

Enums§

RevertError
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 run would do, without touching the document.
revert_changes
Undo several changes, each on its own, into one open transaction: changes pairs 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::diff and mean the same thing on every peer holding the same changes.