Work changes. Kythene keeps the history rather than accumulating near-identical collections called "report", "report v2" and "report final".
Two counters, one idea
- An artifact has versions. Push a new version of
bench.jsonand the previous bytes stay retrievable. - A collection has a revision. It bumps whenever any artifact inside it gets a new version.
So the revision is the collection's "state at a point in time", and it's what comments and approvals pin to.
Push a version instead of publishing again
Ask your instance:
"Push the new benchmark run as a version of the existing Nightly benchmark collection, note that it's after the index change."
You keep one stable link, one comment thread, and a real history. Publishing a second collection instead gives you two links, split feedback, and no way to see what changed.
From the CLI:
kythe version <collection-id> ./bench.json --note "after the index change"Files are matched to the collection's existing artifacts by base name. Where a collection holds a single artifact and you give a single file, it matches regardless of name.
Approvals clear when the work moves
Pushing a version bumps the revision, and that clears the collection's approvals. This is deliberate: an approval means "I signed off on this state", so it can't silently carry over to a state nobody looked at.
Comments don't disappear - they stay pinned to the revision they were left on, so it stays clear which review was against which version. Block-level comments go further and follow the paragraph they were attached to, where it hasn't changed. See Block-level feedback.
Reading an older version
Each artifact's history is on the collection page in the app. From the CLI:
kythe artifact <artifact-id> --version 2 --content
kythe artifact <artifact-id> --version 2 --out ./old-bench.jsonA wiki page's history
A wiki page is a collection underneath, so it gets the same machinery, with its own screen. The history lists every snapshot, marks which one is published and which were previously published, and lets you bring an older one back.
Restoring publishes a new snapshot carrying the old content rather than rewriting history. The old snapshots stay exactly as they were, and the history says plainly that this was a restore. Images travel with it, restored to the versions they were at the time - a restore that brought back the words and left today's pictures would be worse than none.
Discarding unpublished changes is the same act pointed at the published snapshot, which is why the discarded version stays in the history rather than vanishing.
When to publish something new instead
Push a version when it's the same piece of work moving forward. Publish a new collection when it's genuinely a different thing - a different week's report, a different analysis, a different deliverable. If you'd want separate approvals on them, they're separate collections.