Philosopher Daniel Dennett once wrote that “There is no such thing as philosophy-free science, just science that has been conducted without any consideration of its underlying philosophical assumptions.” Something analogous is true for version control systems and any collaborative work place—the question isn’t whether you use one, it’s about how considered and efficient it is.
This might seem like an odd claim, but consider that a version control system is simply the process through which changes to documents are managed. So if you manage your files through imaginative names like “Meeting Report Draft”, “Meeting Report Final”, “Meeting Report Final FINAL”, you are already employing crude version control.
Of course, there are downsides to an informal system like this. Over time you are bound to mix up files, and will have to manually trawl through various folders trying to locate what you are looking for, hoping your past self didn’t use something obscure for the document title. Systematic version control stores all files in a single, easily accessible repository and timestamps each file for easy searches. The use of Word2vec can make this even easier, helping embed timestamped information in image metadata, letting you track down a version any time.
With the use of each file assiduously tracked, collaboration becomes easy because it can be verified that a certain file has been worked on by whoever is in the prior stage of the workflow. The ability to lock a file in use and grant control over when the file becomes editable for someone else ensures that no one starts working on a file before all the work that needs to get done actually gets done. Of course, system administrators can override these locks in case the person who locked the file suddenly gets otherwise occupied. Importantly, the lock controls who can edit the file, but it can still be viewed and downloaded at any time.
Past versions don’t get discarded, but are all stored in the server. This way, they can be referred to in case there are issues or questions, and in case work on a particular version renders it unfixable, previous versions can quickly be switched to and treated as the latest version. This creates a sandbox to try out new ideas without being forced to abide by a tentative choice that was being tried out.
Finally, the fact that multiple versions are stored on the server allows for an incredibly fine-grained catalogue of track changes that documents what the changes are, who made the changes, and when. Additionally, comments about why, when relevant, can be added. This is particularly useful for production processes that are many-layered, because linking comments to a certain set of edits goes a long way in making the system intelligible across the board.
For many publishers, their production process tends to be both intimate and informal, with many of their standard processes having been shaped by the culmination of decisions made over years, sometimes decades. These decisions often reflect the vast amount of experience they gather in the industry, and made with certain real issues in mind. This means sometimes the way they work may feel personalized, like tradition.
The flip side to this is that sometimes there might be some inertia against switching to new systems and new ways or working, because why change something that isn’t broken? Still, I think it’s good to step back once in a while, and ask whether the way you are working is actually logical and whether a simple fix could make things much easier. I think incorporating an official system for version control is one of those things that offer huge pay-outs in productivity and efficiency, while changing little about the way people actually work.