Version control for things you can hold
Applying software change tracking to hardware, and what it took.
Version control for hardware means the same thing it means for software, a reliable way to know exactly what changed between one revision of a design and the next and to be able to go back to any earlier one, but it takes considerably more discipline to achieve, because a physical part cannot simply be copied and stored the way a text file can.
Why copying a file and copying a part are not the same act
A software revision system works because saving a new version of a file costs almost nothing: the computer keeps a complete copy of every earlier draft, cheaply and automatically, so going back to yesterday's version is a matter of asking for it. A machined bracket does not have that luxury. Once a revised version of the bracket has been drawn, cut, and installed, the previous revision does not sit quietly in storage waiting to be recalled, it has usually already been scrapped, or it exists only as whatever physical parts happen to still be sitting in old machines already out in the field. Hardware revision control therefore cannot rely on simply keeping every past version around the way software does, and has to do something software rarely needs to bother with, which is capture the change itself, in writing, precisely enough that an earlier revision could be reconstructed from the record even after every physical example of it is gone.
The photocopied-draft comparison
Keeping track of a hand-written document's history the careful way means photocopying and dating each draft before making the next round of edits, so that any earlier version can always be pulled back out and compared against the current one. A physical part under the same discipline works differently, because there is no equivalent of the photocopier: modifying a machined part usually means machining directly into the only copy that exists, and the earlier geometry is destroyed in the same motion that creates the new one. What takes the place of the photocopy is a written revision note, made before the change is cut, describing exactly what is changing and why, so that the record survives even though the object itself does not. The discipline is the same in spirit, keep an honest trail of what changed and when, but the mechanics are almost opposite: software preserves the object and lets the record be optional, hardware has to preserve the record because the object usually cannot be kept.
Why a physical revision has to be written down rather than simply kept
The underlying reason a physical revision needs an explicit written record, rather than an archived copy of the part, comes down to what a change actually consists of on each side. A software change is data, and data can be duplicated at effectively zero cost, so an entire history of complete versions can be kept without anyone ever needing to summarise what changed between any two of them. A hardware change is a decision, applied to an object, and while the object itself is expensive to duplicate, the decision behind it is not: a sentence describing the change, the reason for it, and which units are affected is nearly as cheap to write down for hardware as an automatic save is for software, even though the underlying artefact behaves completely differently. Recognising that the record, not the object, is the thing being versioned is what makes hardware revision control tractable at all, because it means a company never has to solve the much harder problem of archiving physical copies of every part it has ever superseded.
The number that matters here
A software repository can hold thousands of complete saved revisions of a single file for the storage cost of a few thousand lines of text, while keeping even a handful of superseded physical revisions of a machined part on a shelf, as evidence rather than as record, means literally storing the scrapped parts themselves, at a cost in space and handling that grows with every additional revision kept.
Where this stops being true
Not every physical revision destroys its predecessor, and the distinction matters for how strict the record has to be. A sheet metal bracket cut fresh on each revision genuinely erases the previous geometry the moment new material replaces it, but a bolted sub-assembly built from standard, off-the-shelf parts can sometimes hold two different revisions side by side without much difficulty, since swapping a revised bracket back out for an older one is only a few bolts' worth of work rather than a remake from raw stock. Where reverting is genuinely cheap, the record still matters for knowing which revision is which, but the consequence of an unrecorded change is smaller, since the older revision can often still be produced again on demand rather than only reconstructed from a written description. The harder cases, the ones that actually justify strict discipline, are the parts where a revision is effectively a one-way door: a casting, a moulded part, anything shaped in a process that consumes its previous form entirely on the way to producing the next one.
What this changes in practice
Adopting version control for hardware in practice means every part number carries a revision letter or number alongside it, every drawing states plainly which revision it represents, and every change, however small, gets a written note describing what changed and why before the new revision goes anywhere near a machine. The habit that actually makes this work is treating an unrecorded change to a released part as a serious lapse rather than a shortcut, since a part quietly modified without a matching revision note breaks the entire premise the system depends on, that a given revision number always means the same specific geometry no matter which unit or which year it is found on. The same discipline extends naturally to the bill of materials and the assembly instructions covered earlier in this set, since a revision to a part's geometry very often forces a matching revision to the quantities that reference it or the order in which it gets assembled, and a hardware revision system that only tracks the part while leaving those neighbouring documents to drift out of step quietly reintroduces the exact ambiguity it was built to remove.
My key error with this
For longer than I would like to admit, I believed that a disciplined file-naming convention was version control, so revisions lived in filenames, the current one was whichever had the highest suffix, and the reasoning behind any given change lived in whoever had made it. It works adequately while one person holds the whole picture and fails the moment anybody else needs to know why a dimension changed, because a filename records that something changed without recording what or why, and reconstructing the reason from two similar models is slow, uncertain work. The cost showed up as machines in the field that we could not confidently trace back to a specific revision, which turns any question about a fault into an investigation. Moving hardware changes onto ordinary development tooling, so that each change arrives as a reviewable difference with a written reason attached and a short log of what was actually done, closed that gap almost entirely. What replaced the belief is that version control is not about storing versions, it is about preserving the reasoning that produced them, and a filename has never once carried a reason.