skip to content

You support several release lines from one case repository. Would you clone the case tree per release, or keep one definition marked with the releases it applies to?

level: principalimportance: should knowfreq 44%

answer

  1. copy only what genuinely differs
  2. markers are cheap, copies are permanent
  3. runs are already release-scoped
  4. conditional prose is the smell
  5. price the propagation before copying

basics

~20 s

Copy only what genuinely differs. One definition marked with its applicable releases keeps a single fix site and one continuous history; clone a subtree only where behaviour really diverges, and expect permanent hand-carry for every copy.

solid answer

~50 s

The deciding input is **how much of the suite genuinely differs between the lines**. If it is a small fraction, one shared tree with per-release markers wins outright: one place to fix, one continuous history per case, no propagation cost. If most cases really do read differently per release, a shared definition fills with conditional prose that a tester must resolve before executing, and copies are the honest answer. The reason usually given for cloning - per-release reporting - is normally already solved a layer down, because executions are scoped to a run or cycle that names its release, so results partition by release without duplicating any definition. That leaves the real justification: the *text* differs. In practice the answer is a hybrid - a shared tree, plus a cloned subtree for the parts that genuinely forked - and the ongoing upkeep is proportional to how much you cloned.

go deeper

for a junior

Know the two options exist - a copied tree per release, or one definition marked with the releases it applies to - and that copying means fixing the same thing more than once.

for a middle

Compare the mechanics: where a fix lands, whether a case keeps one continuous history, and how release-specific wording is expressed in each model.

for a senior

Bring the evidence - what share of the suite genuinely differs, and whether release-scoped runs already deliver the reporting the copies were supposed to buy.

for a principal

Own the tradeoff and its exit. Price the recurring propagation against the divergence you actually have, defend a hybrid, and say what would make you change models.

## The two models, and what each actually costs | | Clone a subtree per release | One definition, marked per release | |---|---|---| | Where a fix lands | Once per supported release, by hand | Once | | History per logical case | Split across copies, never joined | Continuous | | Release-specific wording | Natural - each copy just says its own thing | Awkward - conditional prose inside one case | | Finding all versions of a case | Needs a stamped lineage value | It is one case | | Cost trend over time | Grows with the number of supported lines | Flat | | Risk | Copies quietly diverge unnoticed | A change made for one release affects readers on every release | Neither is free. Copying moves the cost to **propagation**; sharing moves it to **conditionality**, where one text has to serve several behaviours. ## The question that actually decides it Measure, or estimate honestly, **what share of the suite genuinely reads differently between the lines**. Not what *might* differ - what does. - A small share: keep one tree. The differing cases are the exception and can be handled individually. - A large share: the lines have forked, and a single definition would need a conditional in most cases. Copy. - Somewhere in between - the common case: a shared tree plus a cloned subtree covering the area that genuinely forked, usually one product area rather than the whole suite. The smell that tells you a shared definition has been pushed too far is **conditional prose**: steps that say one thing for one release and another for the next, so the tester has to decide which branch applies before doing anything. At that point the single case has stopped being one case, and a copy is more honest than the conditional. ## The reporting argument, and why it is usually already answered Teams often clone because they want *results per release*. That is nearly always solved a layer down: an execution belongs to a run or cycle, the run names the release it is for, and the results partition by release without duplicating a single definition. If per-release reporting is the whole justification, cloning is paying a permanent duplication cost to solve a problem the execution layer already solves - and paying it twice, since the split histories then make per-case trends harder rather than easier. Before choosing to clone, force the question: *what do I get from a copy that a release-scoped run does not already give me?* The only durable answer is that the case **text** genuinely differs. ## The upkeep you are signing up for Every copy adds recurring work that never gets cheaper: 1. **Propagation** - each correction is applied once per supported copy, by a person, forever. 2. **Finding the siblings** - free only if a lineage value was stamped when the copy was made. 3. **Audit and classification** - somebody periodically decides which differences were meant and which were missed. 4. **Lifecycle** - when a line stops being supported, its copies must leave the propagation set, or you keep paying for releases nobody ships. Multiply that by the number of supported lines before agreeing to the model, and be explicit that the cost is ongoing headcount, not a one-off setup. ## Signals you chose wrong - Corrections keep landing on only the newest line: propagation is not being followed, and the other copies are accumulating wrong expected results. - The shared tree's cases are full of *if release X, otherwise Y* branches: sharing has been pushed past what one text can carry. - Nobody can list all the copies of a case: the clone model was adopted without the identity discipline that makes it survivable. - The number of markers on a shared case keeps growing until nobody trims them: the shared model is being used as an archive of every release that ever existed rather than a statement about supported ones. The defensible position in an interview is not a blanket preference. It is: *default to one definition, clone the subtree that genuinely forked, and price the propagation before you copy anything.*

  • What would make you switch a shared tree over to per-release copies?
    When a meaningful share of cases needs genuinely different steps per release and the text fills with conditionals. Once a tester must decide which branch applies before executing, the single definition has stopped being one case, and a copy states the difference honestly instead of hiding it in prose.
  • How does the run or cycle layer affect this choice?
    Executions are already scoped: a run names the release it belongs to and carries its own results, so per-release reporting exists without duplicating definitions. That removes the most commonly cited reason to clone and leaves only the real one - the case text genuinely differs between the releases.

saying these in an interview costs you the question

  • Clones the whole tree when only a handful of cases differ
  • Copies the tree to get reporting the run layer already provides
  • Ignores the permanent propagation cost when choosing to clone
  • Buries genuine release differences in conditional case text
  • Picks one model as a blanket rule regardless of divergence