Document version control: knowing which copy is the real one

Document version control is the practice of tracking changes to a document so that everyone can tell which version is current, what changed, and who changed it. The failure it prevents is specific and familiar: two people editing different copies, a decision made from a superseded draft, and nobody able to say which file the customer actually received.

The filename comedy — proposal_final_v2_FINAL_revised — is the visible symptom. The underlying problem is that the document has no single home, so every copy is equally plausible and the name has to carry information the system should be carrying.

What good version control gives you

• One current version, in one place, that everybody links to rather than copies.
• A history you can read: what changed between versions and who made the change.
• The ability to go back. Not theoretically — actually restoring last Tuesday's text in under a minute.
• A distinction between draft and approved, so that people can tell whether they are looking at something in progress or something in force.
• For controlled documents, a record of who approved which version and when — the ground covered in document control system.

Making it work

1. Store documents in one system, and share links rather than attachments. Every emailed copy is a fork you will not be told about.
2. Let the system hold the version. Manual numbering in filenames is only necessary when the system cannot, and it always drifts.
3. Where you must number manually, use a scheme with meaning: major version for approved releases, minor for drafts between them — 1.0, 1.1, 2.0.
4. Record the change, not just the version. A one-line note about what changed is worth more than the number.
5. Name a document owner. Versions proliferate fastest where nobody is responsible for saying which is current.
6. Mark superseded versions clearly, and keep them where they cannot be mistaken for current — but keep them, because reconstructing what was true in March is a routine need.

The moment a document is emailed as an attachment, version control ends. Every recipient now holds a copy that will not update, and at least one of them will edit it and send it back. This is not a discipline problem — it is what attachments are for. If a document matters enough to control, share a link and let people read the current version.

How much control is enough

Most documents need none. A meeting note or a working draft needs a history you could consult and nothing more. The documents that justify real control are the ones where being out of date has consequences: policies, procedures, contracts, specifications, anything an auditor or a customer might hold you to. Applying formal versioning to everything produces ceremony people route around, which is worse than applying it to the ten documents that matter.

Where it lives

Ettex Docs keeps the history per document with named authors, so the current version is the document rather than a file among copies, and sharing works by link — covered in online document sharing. Formal approval and controlled distribution belong in document control system, and how long superseded versions are kept in records retention schedule.

The boundary: this is document versioning, not a source control system. There is no branching, no merge resolution across parallel edits, no diff between arbitrary versions of a binary file. For prose that is the right depth; for code, use the tools built for it.