Rinne
Rinne

Snapshots

A snapshot captures your project folder at a point in time. It is the basic unit of history in Rinne.

What a snapshot is

A snapshot is an immutable record of folder state. You create one with save, then refer to it later with commands such as history, diff, restore, verify, and extract.

The point is simple: when you save, you get a stable checkpoint you can reason about later. History stays readable because each snapshot refers to one concrete project state.

Independent history

Snapshots are not rewritten in place. As you keep saving, you build a non-destructive timeline of states instead of mutating the past.

This is what makes later work practical: you can compare checkpoints, attach intent with notes, or restore an older state without having to guess what used to be true.

Deleting a snapshot removes that snapshot from history, but it does not redefine what the remaining snapshots mean.

How snapshot data is stored

Snapshot structure is tracked through manifest.db. File content is stored in content-addressed storage, so unchanged data can be reused across many snapshots.

This lets Rinne keep dense history efficiently, especially for iteration-heavy work and binary-heavy projects.

When you need normal files again, restore applies a snapshot back into the working folder, and extract writes snapshot content into an external output directory.

  • manifest.db: stores snapshot structure and metadata.
  • CAS: stores file content in reusable chunks.
  • restore / extract: turn stored snapshot data back into regular files.

How snapshots are used

  • save creates a new snapshot.
  • history lists, shows, and resolves snapshots.
  • diff compares snapshots or compares a snapshot with the working folder.
  • restore applies snapshot content back into the workspace.
  • extract writes snapshot content into a separate output directory.
  • verify and validate check integrity from different angles.

Notes

A snapshot stores state. A note stores intent. Together they make history readable.

  • Use notes to record what changed, why you saved, and what should happen next.
  • Use spaces when one timeline should stay separate from another.
  • Use fuse when two snapshots should become one new checkpoint without rewriting the originals.

Early Access note: specific commands and outputs may change. The concepts remain stable.