Every team that edits configuration files or shared documents ends up choosing a way to remember what changed, whether they notice the choice or not. Some edit in place and hope. Some keep folders of dated copies. Some use a full revision system with commit messages. Let us compare the three honestly, with a bias toward what actually works for busy people rather than what looks tidy in a diagram.
The shared problem
All three approaches try to solve the same trouble. People overwrite their best work, then cannot say what changed or why things got worse. A good history lets you compare two states, learn from the difference and roll back when a change turns out to be a mistake. The question is how much effort each method takes and how much clarity it returns.
Option one: edit in place
This is the default. One file, one current state, no extra steps. It is fast and it feels fine, right up to the day something breaks.
What it does well: zero ceremony, nothing to learn, no clutter.
Where it falls down: the old state is gone. You can still recover it from a backup if one exists, but backups tell you when a file changed, not why. For anything people depend on, this is the riskiest option because it leaves the team with memory as the only record.
Best for: scratch files and throwaway experiments where nobody will ever need the earlier state.
Option two: dated copies with a note
Before changing a file, copy it with the date in the name, make the edit, and add a one-line note in a shared log: what changed, why. It is low-tech and works with any file type.
What it does well: works anywhere, needs no tooling, readable by anyone. A non-technical colleague can follow it without training.
Where it falls down: it depends entirely on discipline. If one person forgets to copy first, the trail has a gap. Comparing two versions means opening both files by hand. And as the number of copies grows, folders get crowded.
Best for: small teams, shared documents, and settings changed a few times a month. It is also the best way to build the habit before graduating to heavier tools.
Option three: a proper revision system
Here every change is recorded automatically, each with an author, a time and a message. Comparison between any two points is built in, and rolling back is a standard operation. Teams that practise infrastructure as code lean on this heavily; the learning route covered in an article on growing into a Terraform certification assumes you manage configuration as versioned text.
What it does well: complete, searchable, comparable history with almost no manual copying. It also supports review, so another person can look at a change before it goes live.
Where it falls down: there is a learning curve, and the history is only as good as the messages. A thousand commits labelled “fix” are worth little. The tool records that something changed; you still have to supply the why.
Best for: anything that is code or code-like, anything several people edit at once, and anything where mistakes are costly.
Side by side
- Effort per change: in place is none; dated copies is small but manual; a revision system is small and mostly automatic.
- Quality of the record: in place has none; dated copies is as good as your notes; a revision system is excellent if messages are meaningful.
- Ease of comparison: in place impossible; dated copies awkward; revision system built in.
- Ease of rollback: in place depends on backups; dated copies simple; revision system simple and safe.
- Learning curve: in place none; dated copies minimal; revision system moderate.
The thing all three have in common
The note is what matters. A date and an author tell you little; the reason is what makes a history useful. A short line such as “Lowered the retry count; the old value hammered the downstream service” is worth more than any amount of automatic metadata. Teams that develop a healthy culture around change notes tend to find that their technical practice follows, which fits the thinking in this look at culture and strategy for dependable digital change.
What about plain-text instructions?
Not everything worth versioning is a config file. Reusable written instructions follow the same logic. Promptosia is built around exactly this need: a library of reusable prompt instructions that people can version and publish for others, with earlier revisions kept close at hand. If your team keeps a library of standard wording, the three options above apply to it just as much as they apply to settings.
So which should you choose?
A fair rule of thumb:
- If it is disposable, edit in place and move on.
- If it matters but changes rarely and is edited by one or two people, use dated copies with a note.
- If it is shared, changes often, or breaks things when it goes wrong, use a revision system and insist on meaningful messages.
Most teams end up with a mix, and that is fine. The failure case is not picking the wrong method but picking none and discovering the gap during an outage.
A quick scenario
Imagine a team that shares one settings file for an internal service. A Monday edit raises a limit; a Wednesday edit lowers a timeout; on Friday users complain. With edit-in-place, the team argues. With dated copies, someone opens Monday’s and Wednesday’s files and spots the clash in minutes. With a revision system, the same answer arrives with a built-in comparison and the name of the person to ask. The difference is not the technology so much as the speed at which you reach a shared, factual picture.
Migrating from one to the next
If you currently use dated copies and want to move to a revision system, treat your oldest dated copy as the first entry and import the rest in order, reusing your old notes as messages. You will keep the story you already wrote. It is much nicer than starting from a blank history, and it proves that your earlier discipline paid off.
Going the other direction, from a revision system back to something simpler, is rare, but it happens for non-technical documents that colleagues prefer to handle in an ordinary office file. In that case, keep the dated-copy rules strict.
A closing thought
Whichever approach you choose, the goal is the same: when something changes for the worse, you should be able to answer two questions in under a minute. What changed? And why? If you can, your history is working. If not, you have just located your next small project.