dtourolle/DarkRoom
1
0
Fork 0
Code Issues 39 Pull Requests Actions Packages Projects Releases 20 Wiki Activity

FR-DEV-5 — Named snapshots of an edit state #8

New Issue
Closed
opened 2026-09-05 16:09:18 +00:00 by dtourolle · 2 comments
dtourolle commented 2026-09-05 16:09:18 +00:00
Owner
Copy Link
Copy Source

FR-DEV-5 specifies edit history "persisted with the catalog so history survives a restart" and "named snapshots of an edit state". Neither is built.

Gap

core/dr-pipeline/src/history.rs states this plainly in its own "What this is not, yet" section: the stack is in memory, 64 deep, per session, and closing the image forgets it. It also says why — the gap that mattered was an automatically-saved mis-drag with no way back, and that is what was closed first. That reasoning is sound; this is the remaining half.

Why snapshots first

Snapshots are the cheaper and more valuable half. A snapshot is an EditState, which is exactly what the history stack already holds and what the sidecar already round-trips — so the storage question is largely answered. Full per-step history persistence can follow, or be dropped by an explicit decision.

Snapshots are also what make hold-to-compare worth twice as much: comparing against the original is the honest check, comparing against "the version I liked twenty minutes ago" is how a photographer actually decides between two treatments.

Acceptance

  • Name, save, list, restore and delete a snapshot of the current edit.
  • Persisted in the sidecar, so it survives a restart and syncs between devices per field (FR-NC-9).
  • Restoring a snapshot is one history step, undoable.
  • A snapshot costs one EditState, not one rendered image.

Enables

Hold-to-compare against a chosen snapshot — FR-DEV-7's second clause.

Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.

FR-DEV-5 specifies edit history "persisted with the catalog so history survives a restart" and "**named snapshots** of an edit state". Neither is built. ## Gap `core/dr-pipeline/src/history.rs` states this plainly in its own "What this is not, yet" section: the stack is in memory, 64 deep, per session, and closing the image forgets it. It also says why — the gap that mattered was an automatically-saved mis-drag with no way back, and that is what was closed first. That reasoning is sound; this is the remaining half. ## Why snapshots first Snapshots are the cheaper and more valuable half. A snapshot **is** an `EditState`, which is exactly what the history stack already holds and what the sidecar already round-trips — so the storage question is largely answered. Full per-step history persistence can follow, or be dropped by an explicit decision. Snapshots are also what make hold-to-compare worth twice as much: comparing against the original is the honest check, comparing against "the version I liked twenty minutes ago" is how a photographer actually decides between two treatments. ## Acceptance - [ ] Name, save, list, restore and delete a snapshot of the current edit. - [ ] Persisted in the sidecar, so it survives a restart and syncs between devices per field (FR-NC-9). - [ ] Restoring a snapshot is one history step, undoable. - [ ] A snapshot costs one `EditState`, not one rendered image. ## Enables Hold-to-compare against a chosen snapshot — FR-DEV-7's second clause. --- Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.
dtourolle added the developpipelineunmet-requirementsize:M labels 2026-09-05 16:09:18 +00:00
dtourolle commented 2026-09-05 16:09:50 +00:00
Author
Owner
Copy Link
Copy Source

Closes the second clause of #14, once #3 accepts a snapshot as its comparison target.
Reduces the urgency of #11 — snapshots cover a good part of what variants are wanted for, at a fraction of the cost.

**Closes the second clause of** #14, once #3 accepts a snapshot as its comparison target. **Reduces the urgency of** #11 — snapshots cover a good part of what variants are wanted for, at a fraction of the cost.
dtourolle commented 2026-09-19 10:19:17 +00:00
Author
Owner
Copy Link
Copy Source

Landed in d3b6127 (2026-09-12): a snapshot is a sidecar version carrying snapshot-of = <uuid>, nameable, restorable, and mergeable like any version. FR-DEV-5 is tagged in ten files.

Landed in d3b6127 (2026-09-12): a snapshot is a sidecar version carrying `snapshot-of = <uuid>`, nameable, restorable, and mergeable like any version. FR-DEV-5 is tagged in ten files.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibility
 android
apps/darkroom-android and the platform contract
 blocked
Cannot start until something else lands
 catalog
core/dr-catalog and the data model
 culling
Selection, comparison and the culling surfaces
 decision
Needs a decision recorded, not code
 develop
The develop view and its pipeline
 docs
An edit to the register of record
 ergonomics
How the work feels to do, not what it computes
 gpu
core/dr-gpu and the render path
 i18n
Localisation
 linux
Desktop packaging, portals and distribution
 masks
Local adjustments and selection
 performance
Budgets, benchmarks and frame timing
 pipeline
core/dr-pipeline
 plugins
The plugin host and the declarative format
 post-v1
Specified as the design of record; outside the v1 count
 size:L
A subsystem, not a feature
 size:M
Days
 size:S
Hours to a day
 spike
A validation spike from requirements §9
 sync
dr-sync and the Nextcloud backends
 ui
ui/dr-ui
 unmet-requirement
An existing requirement that is specified but not built
No labels develop pipeline size:M unmet-requirement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
dtourolle (Duncan Tourolle)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dtourolle/DarkRoom#8