Established onAny spreadsheet, any versionAny electronic mail systemNo mechanism anywhere for combining the results
The entry in the first part of this site described what a version history does and does not record. This one is about the arrangement most organisations actually use, which is not a version history at all.
Versioning by attachment
A file is sent to four people. Three edit it and send it back. The names arrive as budget final, budget final one in brackets, budget FINAL version three, and a fifth with somebody's initials on the end.
The file name is now the only version information in existence, it was written by whoever pressed save, and there is no rule about what any of it means.
What has actually happened
The work has forked. Three people made changes to the same starting point, and those changes now exist only in three separate files, with no mechanism for combining them.
Merging is manual: somebody opens all four, compares them by eye, and retypes. That process is undocumented, unreviewed, and is where changes get lost, which is the point of this entry.
Why the losses are invisible
The person merging cannot see what changed; they can only see what the files contain now. A correction somebody made in one copy is indistinguishable from a value that was always there, so overwriting it with the original produces no error and no signal.
The corrected figure simply disappears, and the person who made it will assume it was applied.
Why nobody stops
Because attaching a file is one action and works everywhere, and every alternative requires that both parties have access to the same place, with accounts, permissions and a habit. That comparison is decided by the recipient's situation rather than by anybody's preference.
This is the same argument that decides several of the other outcomes on this site: the arrangement requiring no coordination wins over the better one requiring some.
What actually reduces it
A single location that everybody edits, which the next entry is about, and which removes the fork rather than managing it.
Where that is not possible, the workable substitute is a rule that only one named person edits and everybody else comments. It sounds bureaucratic and it converts a merge problem into a queue, which is a problem people know how to solve.
Naming, if copies are unavoidable
Put the date in the name in the descending written form described in the entry on dates, because it sorts correctly in every file listing, and put nothing else about the version in it.
Never use the word final. It is not a claim anybody can make about a file they are sending to somebody else for comment, and every organisation has files named final that were not.
The copy that is a snapshot
One legitimate use of a copy: a frozen record of what was presented or submitted on a particular date, kept read-only and never edited. That is an archive rather than a version, and naming it accordingly separates it from the working file.
Where a figure has been acted on, having the exact file it came from is worth the disk space, and it answers questions that no version history answers well.
What to do with the pile you already have
Pick the one that is current, put it in the shared location, and move every other copy somewhere clearly marked as superseded rather than deleting them. Deleting is tempting and somebody will eventually need to know what a superseded copy contained.
Then compare the current one against the second most recent, cell by cell where it matters, because the pile exists precisely because nobody knows what differs.
What we cannot verify
This entry describes a pattern of practice rather than software behaviour, so there is nothing here documented by a vendor. The description reflects what is observably common in organisations; we have not measured how common, and no figure is offered.
The version of this in shared drives
Moving files to a shared folder removes the electronic mail step and not the pattern: people copy the file to work on it, because editing something others are looking at feels rude, and the copies reappear with different names in the same folder.
The shared location only helps when it is also the place edits happen, which requires the simultaneous editing described in the next entry.
The comparison tool nobody uses
Excel ships a separate application for comparing two workbooks, which reports differences in values, formulas and formatting between them. It is installed with some editions and not others and it is the only practical way to answer what changed between two copies.
Where a pile of copies already exists, that tool is the fastest route through it, and most people who have the pile do not know it is on their machine.
What a fork costs in time
Reconciling four copies of a workbook of any size is a day's work performed by somebody senior enough to judge which value is right. That cost is paid every cycle and is invisible in every measure of how long the work takes, because it is filed as reviewing rather than as merging.
In short
- The file name becomes the only version information, written by whoever pressed save.
- Three edited copies are a fork with no mechanism for combining them.
- Merging by eye loses changes silently, because a correction looks like an original value.
- Attaching a file requires no coordination, which is why the practice survives.
- A single shared location removes the fork rather than managing it.
- Date the copies in descending written form and never use the word final.