FR-DEV-15 — More than one edit variant per photograph #11

New Issue

2026-09-05T16:09:20Z

dtourolle commented

2026-09-05 16:09:20 +00:00

A photograph shall be able to carry more than one edit variant, created and switched from the develop view.

Why

The mono version, the tighter crop, the client's alternative — held at once rather than chosen between. Branching is what makes an irreversible-feeling decision reversible, and it is the answer to "this crop for print, that one for the web" that does not involve editing the frame twice.

The data model already anticipates this. VersionId in core/dr-types/src/lib.rs:41 is documented as "one edit variant of an image (a virtual copy)"; dr-catalog's schema and keywords.rs both already reason about virtual copies. Nothing in develop creates one.

Acceptance

Create, name, switch, and delete a variant from the develop view.
A variant costs one sidecar, not one raw file.
Ratings, keywords and people stay attached to the photograph, per the rule keywords.rs already states and tests.
Variants sync per field like any other sidecar (FR-NC-9).
The grid shows variants in a way that does not double the apparent size of the library.
Export names variants distinguishably.

Cost

The largest item in the Develop Ergonomics spec, and the only one that is a subsystem rather than a develop feature — it reaches the catalog, the grid, the sidecar and export. Worth staging behind the cheaper comparison work (hold-to-compare, snapshots), which covers a good part of the same need for much less.

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

A photograph shall be able to carry **more than one edit variant**, created and switched from the develop view. ## Why The mono version, the tighter crop, the client's alternative — held at once rather than chosen between. Branching is what makes an irreversible-feeling decision reversible, and it is the answer to "this crop for print, that one for the web" that does not involve editing the frame twice. The data model already anticipates this. `VersionId` in `core/dr-types/src/lib.rs:41` is documented as "one edit variant of an image (a virtual copy)"; `dr-catalog`'s schema and `keywords.rs` both already reason about virtual copies. Nothing in develop creates one. ## Acceptance - [ ] Create, name, switch, and delete a variant from the develop view. - [ ] A variant costs **one sidecar**, not one raw file. - [ ] Ratings, keywords and people stay attached to the *photograph*, per the rule `keywords.rs` already states and tests. - [ ] Variants sync per field like any other sidecar (FR-NC-9). - [ ] The grid shows variants in a way that does not double the apparent size of the library. - [ ] Export names variants distinguishably. ## Cost The largest item in the Develop Ergonomics spec, and the only one that is a **subsystem rather than a develop feature** — it reaches the catalog, the grid, the sidecar and export. Worth staging behind the cheaper comparison work (hold-to-compare, snapshots), which covers a good part of the same need for much less. --- Part of the Develop Ergonomics spec (FR-DEV series proposal), 2026-09-05.

dtourolle added the develop pipeline catalog size:L labels 2026-09-05 16:09:20 +00:00

dtourolle referenced this issue

2026-09-05 16:09:50 +00:00

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

dtourolle commented

2026-09-05 16:09:51 +00:00

Stage behind #3 and #8. Held comparison and named snapshots cover a good part of the same need for a fraction of the cost; do them first and re-judge whether this is still wanted at this size.

**Stage behind** #3 and #8. Held comparison and named snapshots cover a good part of the same need for a fraction of the cost; do them first and re-judge whether this is still wanted at this size.

dtourolle referenced this issue

2026-09-26 00:44:57 +00:00

FR-CAT-11 — Consolidate duplicate originals into one RAW, keeping every edit #67

dtourolle added a new dependency 2026-09-26 00:45:03 +00:00

#67 FR-CAT-11 — Consolidate duplicate originals into one RAW, keeping every edit

dtourolle commented

2026-09-26 00:45:04 +00:00

Now also needed by #67 (consolidating duplicate originals): when copies of one RAW carry different edits, those edits become virtual copies on the file that survives, so this is what lets #67 merge a group without losing processing.