History of Version Control Systems: Part 2
Part I: First-generation
Part II: Client/Server
Part III: Distributed
The first generation of version control systems enabled collaboration, but three things changed – codebases grew, the number of programmers grew, and even the ratio of programmers to projects grew.
Local version control on time-sharing UNIX machines didn't scale anymore. Networking computers were the major unlock – they enabled client/server architectures. The client/server model also had another feature – it was also commercially viable. Project-level tracking allowed for atomic commits across files and easier versioning.
The second generation of version control systems introduced project-level concepts like repositories and new ways to collaborate – merging as an alternative to locking, branches, and networked file systems.
Some of the most popular VCSs in the second generation were CVS, ClearCase, and Perforce.
Concurrent Versioning System (CVS) – 1986. CVS was a front-end for RCS. RCS managed files, not projects. CVS introduced the concept of a repository. While RCS had a concept of file locking, CVS loosened the restriction and defaulted to a merge model to resolve conflicts. It also was one of the first VCS to introduce branching and symbolic tags.
ClearCase – 1992. One of the first commercial VCS. ClearCase optimized by offloading storage from the local disk to networked file storage. It was originally developed by Atria, which later merged with Pure Software (founded by Reed Hastings, who later founded Netflix).
Perforce – 1995. One of the first VCS to have what resembled a modern branching and merging system. Decoupled permissions, access control, and storage from the operating system. As a result, Perforce scaled (in terms of repository size, not the number of collaborators) fairly well, even for larger files.
Google originally used Perforce (now it's an amalgamated monster of git, perforce, and other APIs).
Subversion – 2000. Subversion was the open-source and eventually Apache-incubated client/server VCS. Subversion was largely built to fix the issues in CVS that showed up in the other commercial systems – atomic commits, branching, merging (and file locking), binary file versioning, and client/server architecture.
SourceForge originally supported CVS and later SVN (and finally the third-generation DVCS).
Next: Part III: Distributed