In a managed test case repository, how does comparing two revisions of a case differ from restoring one, and what does a restore leave behind in the trail?

Every managed case repository that keeps a per-field change history offers two operations on top of it, and candidates routinely conflate them. One is a **read** across two points in the trail. The other is a **write** whose values happen to come from the past. Getting the difference right also settles the question interviewers really care about: what a restore does to the record. ## Comparing: a read across two points A comparison names two revisions of the same case and renders the difference between them field by field: the title then and now, the preconditions then and now, and so on. Three properties matter. - It **changes nothing**. Running it a hundred times leaves the case and the trail exactly as they were, and it adds no entry of its own. - It is normally available to **anyone who can read the case**, because reading two stored states is not a privileged act. - It is **derived, not stored**. The product computes it from the entries; there is no comparison object sitting anywhere. The one place comparison misleads is the same place the underlying entries are thin. If step edits are journaled as a bare marker rather than as per-row before-and-after text, the comparison inherits that thinness — it will tell you the steps differ without telling you how. ## Restoring: a write that points backwards A restore reads an older revision, takes its values, and **saves them onto the live case as a new edit**. That is the whole mechanism, and every consequence follows from it: 1. **A new revision is appended.** Its actor is whoever pressed restore, and its timestamp is the moment of the restore — not the original author, not the original date. 2. **Its rows read backwards.** The before values are today's text; the after values are the old text. Someone reading the trail later sees a normal edit that happens to move the fields back. 3. **Nothing between is removed.** Every revision you restored past is still there in order. The trail is longer after a restore than before it, never shorter. | | Compare | Restore | |---|---|---| | Effect on the case | None | Live fields are overwritten with old values | | Effect on the trail | None | One new revision appended | | Attributed to | Nobody | The person who restored, at the current time | | Typical permission | View | Edit, sometimes a distinct restore right | ## What a restore does not bring back This is where the mechanism disappoints people who expected a time machine. A restore covers **versioned fields** and generally nothing else: - **Attachments** are usually not restored with the text — the trail records that a file was added or removed, not the bytes to put back. - **Comments and discussion** are their own stream, not case fields, so they are untouched. - **Anything the case merely points at** — a shared step definition, a referenced dataset, a linked tracker item — keeps whatever value it has today. Restoring the case's own text does not reach through those references. So a restored case can be a faithful copy of the old wording and still not be the old case in every respect. Say that out loud in an interview; it is the detail that separates someone who has used a restore from someone who has read about one. ## Permissions and etiquette Because a restore silently replaces the current text of a shared artefact, products commonly gate it more tightly than ordinary editing, and teams add convention on top: - Leave a **reason** — a comment on the case, or a note in whatever your team reads — because the revision itself records only what moved, never why. - Prefer restoring **into a visible moment**, not quietly at the end of a day, when other people may be working from the current wording. - Check for concurrent edits first: a restore is a full overwrite of the fields it covers, so an edit someone else made minutes ago disappears from the live case even though it survives in the trail. ## Why append-only is the point Occasionally someone asks for the tidy version: restore the case and make the intervening revisions go away, so the history reads as though the bad edit never happened. Refuse it. A trail is worth something only because entries cannot be removed by the people whose work they describe. The moment a revision can be deleted, no revision proves anything, and every earlier answer the history gave becomes unreliable. Fix forward — the correction is another entry, and the entry that was wrong stays visible above it.