Overgrown history needs a merge policy so the list stays readable

What it is

Autosave can write a hundred rows in a day. A flat list makes milestones unscannable; history is unusable. Compaction buckets by time or “no material change” into expandable summaries so the first screen remains a readable timeline. The objects often still exist—they simply do not each own a row. That is not expiry. Retention says whether they will be deleted; compaction says how they are read. Explicit saves should not vanish into an autosave bucket.

Why it happens

Readability is list length versus meaning per row. Meaning is “how this row differs from the last.” Adjacent autosaves often differ by a few characters; a full row adds no information and spends a saccade. Compaction groups by hour or by a run of autosaves, with a range and “about n autosaves,” expandable on demand. If it swallows explicit saves too, the monuments disappear. If groups cannot expand, those autosaves go from openable to unreachable, and loss-prevention dies. A hard cap (keep 50) drops the afternoon of a busy day—that is deletion dressed as compaction. Group boundaries have to make sense: two days’ drafts should not share one group.

Studying it

Build a history with many autosaves and a few explicit points. Ask people to find “what you saved this morning” and to open the last autosave before a crash. Compare flat, hour-folded and expandable, hard-truncated to the last N.

Independent variables: folding rule, whether explicit points stay as their own rows, whether a group expands to every snapshot. Dependent variables: time to an explicit point, belief that in-between autosaves were deleted, ability to open a specific row after expand.

A lab list of a dozen rows does not need compaction. Make enough autosaves that scrolling is required. Do not count a 30-day delete as a fold failure.

Where it stops holding

A sparse manual-checkpoint list needs no compaction. When law requires every change flat for audit, folding can only be a view; export and audit APIs stay flat. If the algorithm destroys underlying snapshots to save storage, that is retention and must be stated as deletion, not a UI fold. “By day” groups across time zones should name the document’s or author’s zone, or boundary rows land in the wrong group.

Applying it

• Default-fold runs of autosaves into time buckets. Explicit saves, publishes, and named versions stay as their own rows.
• Every group expands to concrete snapshots; after expand, compare and restore still work.
• Do not fake folding with “keep the last 50.” If rows must go, use an explicit retention delete.
• Verify: among a hundred autosaves, two explicit saves are findable without walking every row. Expanding an hour bucket opens one autosave inside it. Ask whether folded points still exist; the answer should be yes, not “deleted.”

Related

• Within the group: H8.11.1 Rollback must account for unsynced collaborator edits · H8.11.2 Diffs must show the actual change, not a whole-block swap · H8.11.3 Autosave versions and explicit saves need distinct marks
• Adjacent: H8.06 Version History · H8.14 Content Lifecycle and Archiving
• Search terms: history compaction · version grouping · snapshot fold