Versions and Baselines

## What cloning a subtree actually does In a managed case repository - a TestRail-class product, or a Jira-resident tool such as Xray or Zephyr that lives inside the tracker rather than beside it - a test case is a **record**: a title, an optional precondition, an ordered list of steps with expected results, a set of custom field values, attachments, and a position in a folder or suite tree. Cloning for a release is a **bulk copy of one subtree of that structure**: the folder that held the outgoing release's cases is copied, and the copy becomes the next release's folder. The copy is a copy. Each new case is a **new record with its own identifier**, created now. Nothing about it is a view onto the original, and nothing keeps the two in step afterwards. They are related only by your naming convention and by whatever provenance marker the product happened to write. ## What the copy carries - **The definition** - title, precondition, steps and expected results, exactly as they read at the moment of the copy. - **Custom field values**, to the extent that the destination defines the same fields with compatible types and option lists. A field the destination does not have has nowhere to land, and the value is quietly gone. - **Attachments**, usually re-attached as fresh copies so the new case does not depend on the old one surviving. - **The shape of the subtree** - folders, their nesting and their order, reproduced under the new root. - **Sometimes a provenance note** naming the source case, if the product writes one and nobody strips it. ## What the copy drops | Left behind | Why | |---|---| | Executions and recorded results | A result hangs off a run and names the case it was recorded against - the original's identifier, never the copy's | | The revision trail | The copy is a new record; its history begins at creation, with no entries from before the clone | | Inbound links | Tickets, requirements and external references were written against the original's identifier and keep resolving there | | Saved filters, dashboards and subscriptions keyed by identifier | They were built against identifiers the copy does not share | The drop that surprises people most is the **history**. A year of green runs against the outgoing release's cases is still there and still readable - but it is attached to those cases. The new copy starts with nothing. Any question of the form *how has this case behaved over time* now splits into two reads, one per identifier, with nothing in the product joining them. ## Why the drops matter in practice 1. **Per-case reporting fragments.** Trend views, flakiness views and last-result columns are all keyed by identifier, so the same logical case appears as two unrelated rows the moment it is cloned. Nothing is lost, but nothing is joined either. 2. **Inbound references stay on the original.** A defect ticket that links to the case it was found by still links to the outgoing release's copy. Readers following that link land on a case the current release is not executing. 3. **Freshness signals reset.** Every copied case looks newly created and never executed, so views such as *never run* or *not updated recently* fill up with the whole new subtree on day one, and stay noisy until the first cycle. 4. **Field loss is silent.** When the destination's field set differs, values do not error - they simply are not there. The cheapest moment to notice is immediately after the clone, on a spot check of a handful of copied cases. ## What to check before the first clone - Does the destination define **the same custom fields**, with the same types and the same allowed values? - Do attachments arrive as independent copies, or as references that break if the source case is later removed? - Does the product write a **provenance marker**, and is it something you can filter on months later? - Where do inbound external links end up - on the original, on the copy, or duplicated onto both? - Is the clone easy to undo? Removing a mis-cloned subtree of several hundred cases is not always a single action, and doing it by hand is how cases from the previous release get deleted by accident. Answering these once, before the first release copy, is far cheaper than discovering the answers on the third. The clone itself takes seconds; every consequence above is discovered weeks later by someone who did not run it.