That era was also known as the “copy-paste-rename” era. In the early 1980s and 90s, we evolved from punch cards to hard drives for code, but developers at that time didn’t have the tools to track it. They used to copy and rename folders for version management and share code with other developers via flash drives or emails. And this is where a new chaos began, which led to the birth of version control systems.

The Problems before version control software existence

Version Hell

Without a proper tool to manage the versions of code either parts or a whole software the developers soon started to feel the problem of tracking versions. the codebase soon looked like:

• feature.js

• feature_v1.js

• feature_backup_v1.js

• feature_v2.js

This soon became a problem. The size was increasing unnecessarily, people don’t know the current version, they aren’t able to track changes, etc. These lead to frequent conflicts, software crashes, increased Time-to-market and hence increasing overall cost.

The Integration Hell

Without a proper version control system people are sharing code as a whole. Now suppose you are working on feature A and you’re teammate is working on feature B. Both of you modified a shared file like config or main file. Now when you both want to merge it to the main server you have your own two folders and don’t have a way to track changes. you have to go line by line and this will take a lot of time and effort. Also this will increase chances of human errors and if there are other team members as well they now have to sync the current code with their own versions via this same process.

Undo Impossibility

Suppose someone changed a critical piece of code and you copied it without checking. you found the problem later but you can’t undo the changes to previous state as there is no previous state to fallback to. Even you find the previous code versions, in most cases you might not be able to tell which was the previous version used here and as developers we don’t like uncertainty for something critical.

Accountability Mismatch Problem

Suppose someone from the team changed a shared piece of code and you copied it as it is. now you probably don’t know how, when, why and by whom that piece of code is changed. who is accountable for the changes. Or you found a new addition in the shared code and you want to find why and who added that until you will ask everyone manually who did this and why.

And the list goes on and on with more syncing or mismatching problems people faced at that time.

The Solution

The solution evolved in three distinct generations, each trying to solve the bottlenecks of the previous one.

Generation 1: Local & Locking

Tools: SCCS, RCS.

The initial attempt was the Locking Model. If Developer A "checks out" the file to edit it, Developer B cannot touch it. They have to wait until A unlocks it. It solved the "Overwrite Problem" (Version Hell). Two people couldn't destroy each other's work because only one could write at a time. But It created the "Waiting Line" issue. If you needed to edit critical_feature.js but your colleague had it locked and went to lunch, you were stuck. Development speed was strictly limited.

Generation 2: Centralized Version Control

Tools: SVN

Next we moved to a Merge-Before-Commit model. In this, a central server held the "Truth". Developers checked out files, made changes, and tried to push them back. If someone else changed the file in meantime you need to download their version and merge it with yours. This solved Integration Hell. Multiple people could work on the same project simultaneously. But It introduced the Single Point of Failure. If the central server went down, no one could commit code, look at history, or revert changes. Nothing will work without an internet connection to the server.

Generation 3: Distributed Version Control

Tools: Git

This is the modern standard (Decentralized VCS). Instead of just checking out the latest version of the code, every developer mirrors the entire repository (files, changes, and version history) locally on their machine. This finally solved the Accountability and Undo problems completely. Since developers have the whole history locally, they can commit changes or browse old versions locally. Operations are instant because they happen on local hard drive. If the main server dies, any developer's computer contains a full backup of the project history that can be restored immediately.

Summary

We went from renaming folders (final_v3.zip) to a system where every line of code has a git hash pointing to who wrote it and when.