Anti-pattern: Time Machine

The nature of version control keeps track of every change in the source code give software technology team a perception of version control can be used as a time machine.  Thus you’ll hear the saying like “I should be able to check out any version of the history and reproduce the system at that point”. However, at a very general level, especially for modern commercial systems, such a time machine is an illusion.

Modern commercial systems usually constituted of multiple data sources, components,  dependencies, and connections to the outside world. Just by checking out the source code of the system itself is far away from sufficient to reproduce a pass version of a system. For example, it’ll be very hard to roll back the multiple data sources to that specific point one is looking for, let alone sometimes these data sources are external and you don’t have full control of. Another stronger case is when the systems rely on external APIs, such as Facebook or Twitter or whatever black-box-vendor the systems depend on, one won’t be able to roll back the entire universe.

Noted the above argument is based on a very general level of assumption. For the specific case-by-case basis, one can absolutely construct a time machine to travel back and forth in a small scope. And version control can be the backbone of that toolbox. But such a practice shall have a strictly defined boundary, and be knowing what this practice is capable of and what it is not.

Without the value of version control being our time machine, what’s the primary purpose and value of version control then? It’s a collaboration and audition tool, just like bookkeeping in finance. You can audit what had happened in the source code back in the history, and also easily share the every state change in a codebase on a larger scale team.

Thus I conclude: On a general level, bending version control system to work like a time machine is an anti-pattern. It’s an unrealistic expectation for a collaboration and audition tool.