From CVS to Git, thirty years of source control, lived from inside
Pangram verdict · v3.3
We believe that this document is primarily human-written, with some AI-generated content detected
AI likelihood · overall
MixedArticle text · 1,736 words · 5 segments analyzed
0x07│ 2026.04.28│ 10 min read │ git · version-control · source-control · cvs · subversion · sourcesafe · history · programming · dvcs · github · opinion │ history (v1)
In April 2005, Linus Torvalds wrote Git in ten days because BitKeeper revoked its free licence to the Linux kernel. Twenty-one years later, no successor has emerged. A practitioner's history of source control from someone who used every major system since 1990, and lost code in most of them.
EvilGenius⏱ 10 min ▸ 11 tags
From CVS to Git, thirty years of source control, lived from insideIn 1996 I was tracking source for a development shop, and the system was zip files. Filename was the project name plus the date. Backup was a tape that got rotated weekly. Branches were "copy the directory and rename it." Merging was Beyond Compare and a printout, and on a bad week it was Beyond Compare and an argument. We weren't unusual. Visual SourceSafe was the alternative for Microsoft shops, and Visual SourceSafe corrupted its own database often enough that "maintain offline backups of the SourceSafe repository" was a documented IT procedure, not a worst-case scenario.Thirty years later I work in Git. Every shop I know works in Git. The thing called "modern source control" is the thing one Finnish kernel developer wrote in ten days in April 2005, and twenty-one years later there is no successor on the horizon. The reason is structural. Here's the path from there to here, lived from inside.The pre-VCS era, what we did before formal version control existedPractitioners who came up after 2010 may not know how bad it was. The before-picture is worth painting because it explains why the systems that followed look the way they do. Every choice in CVS, Visual SourceSafe, and eventually Git was a reaction to one of these failure modes.There were zip files with date filenames. project-2003-04-15.zip.
Endless archives in a backup directory, and on Monday morning the conversation was always "I think the working version is in last Tuesday's zip" because Friday's zip had a bug nobody could remember introducing. There were network shares with manual versioning: FINAL, FINAL_v2, FINAL_FINAL, FINAL_REALLY, FINAL_USE_THIS_ONE. The joke that's only a joke because everyone lived through it. Old VAX/VMS systems versioned every save at the file-system level: MYFILE.TXT;3 was version three of the file, automatic, transparent, and a long-dead generation of VMS users still remember it fondly because nothing since has been quite so seamless. There was lock-by-whiteboard and lock-by-email ("I'm editing UTILS.BAS, don't touch it"), which was office practice in many shops well into the late 1990s. And every developer carried a small stack of dated 3.5-inch floppies with "the working version" on them, the personal version of the network share.The argument for paying attention to any of this: before formal version control, every developer maintained their own ad-hoc system, and most of them were bad. The "I had a script that zipped my source tree every night" developer is the same human who later checked things into Git, just with worse tools and more anxiety.The lock-based era, SCCS and RCSThe first formal systems came out of Bell Labs and the early Unix research community.SCCS, Source Code Control System, landed in 1972, written by Marc Rochkind. File-based, single-user, lock-based. Still ships with some Unixes today, usually as a footnote in the man pages. RCS, Revision Control System, followed in 1982 from Walter Tichy at Purdue, with better delta storage and per-file revision tracking, and it's still the substrate underneath several later systems. Both were lock-based. To edit a file under RCS you ran co -l, which marked the file as locked and let you edit it; everyone else was blocked until you ran ci. One file at a time. No notion of a project yet. The unit of versioning was the individual file.What this era taught the rest of source control was the vocabulary. Deltas, meaning diffs between revisions stored efficiently. Check-out and check-in. History as a first-class concept.
RCS's storage format, the ,v files, became the on-disk substrate for CVS a few years later. The lock-based era was correct given its constraints (single workstation, no real network) and wrong for any larger team. The next thirty years of version control history is a sequence of attempts to lift those constraints.CVS, concurrent edits, server-based, badlyThe first system that scaled, and the one that dominated open source from roughly 1990 to 2005.Dick Grune wrote the original CVS, Concurrent Versions System, in 1986. Brian Berliner took it over in 1989 and shipped what most people remember. CVS sat on top of RCS and used those ,v files as its per-file storage backend, but it added the thing that mattered: concurrent edits. Multiple developers could check out and edit the same file, and CVS would merge their changes on commit. That single change killed the lock-based model for serious open-source work and introduced the concept of a repository as a first-class artifact, a thing you cloned, contributed to, and tagged.What CVS didn't solve, and what made it eventually unbearable, was almost everything else. There were no atomic commits; a commit that touched five files committed each one separately, and if the network died halfway through, the repository was in an inconsistent state and someone had to reconcile it manually. Branches existed but creating one was slow, sometimes minutes for a large repository, and merging was manual and brittle. Renames were not tracked at all; moving a file meant deleting it and re-adding it, losing the entire history. Binary files were second-class because diffs assumed text. There was no directory versioning; you couldn't version the structure of the project, only the files in it. And the repository itself was a fragile pile of ,v files on a server somewhere; backup was IT's problem, and if the server's disk failed, history was gone.Anyone who used CVS for serious work in the 1995 to 2005 window has stories. The merge conflict on commit where half the files committed and half didn't, leaving the trunk in a state nobody could describe. The slow-branch problem, where the team avoided branching because it took five minutes to create one and an afternoon to merge it.
The "someone deleted a directory and CVS lost its mind" class of bug. CVS dominated despite all of this because it was free, it was on every Unix, and there was no real alternative until 2000. Open-source projects ran on it because the alternative was nothing.Visual SourceSafe, the parallel commercial trackWhile the Unix world was working through CVS, the Microsoft world had its own track, and most VB6 and early-.NET developers actually lived in Visual SourceSafe.SourceSafe started in 1992 at One Tree Software in Mountain View. Microsoft acquired the company in 1994 and re-released the product as Visual SourceSafe, bundled with Visual Studio, Visual Basic, and various Microsoft developer products through to roughly the mid-2000s. The model was lock-based pessimistic concurrency by default. Check out a file, edit it, check it back in. Other developers could see the file but not edit it during the lock. Multi-checkout was possible but dangerous because VSS's merge tooling was crude and most teams had a verbal rule against it. Microsoft picked the safer-feeling locking discipline where Unix went the other way, and made it the default for an entire generation of Windows developers.The infamous part was the corruption. VSS stored its data in a custom file-database, .dat files in a shared network directory, and the format was fragile. Concurrent access, especially over slow or flaky network shares, could corrupt the database. "The VSS database is corrupt, run Analyze, restore from last night's backup if Analyze can't fix it" was a documented IT procedure in Microsoft shops, not a worst-case scenario. Everyone who used VSS in production has at least one corruption story, and the ones who don't are the ones who got out before they were due.The mental tax was the other piece. Locking discipline meant developers couldn't work in parallel on overlapping code without coordinating verbally. "Hey, are you done with frmMain.frm yet?" was the daily nine-am standup question in shops I worked with through the late nineties. Branches existed but were rarely used because branching was slow and merging was painful, so the typical VSS shop maintained a single trunk and shipped from it.VSS persisted despite all of this because it came with Visual Studio.
It integrated cleanly with the Microsoft toolchain, it worked-ish for small teams on local networks, and the alternative was CVS (which Windows shops mostly didn't use) or no source control at all, which was the actual default for a depressing fraction of Microsoft-shop projects in the late nineties. Microsoft eventually replaced VSS with Team Foundation Server in 2005, which became Azure DevOps, and by the late 2000s VSS was deprecated. Most shops migrated to TFS, or once Git arrived and didn't suck, jumped straight to Git.Subversion, "CVS done right"The thing that should have won, and almost did, before Git arrived two years later.CollabNet started Subversion in 2000, with the explicit pitch of "CVS done right." It became an Apache top-level project, and the first stable release, 1.0, shipped in February 2004. Designed by people who knew CVS's flaws and addressed them line by line.What SVN fixed was substantial. Atomic commits, where multi-file commits succeed or fail as a whole and the repository is never left half-updated. Real branching, with cheap server-side copies, so branches and tags became first-class operations rather than afternoon-long procedures. Directory versioning, which meant renames were tracked and the project's structure was versioned alongside file contents. Binary files were first-class. The client-server protocol was WebDAV-based and played well with HTTP infrastructure, which mattered for shops that had to push source control through corporate proxies.What SVN didn't fix was the fundamental centralized model. You could not commit without a network connection. The repository was still a single server. "Working offline" meant "reading-only", you could browse history but not record any new work, and the day the server was down was the day the whole team waited.SVN almost won. From 2004 to 2008 it was the obvious choice for "better than CVS", and a great many projects migrated CVS to SVN with no awareness that the distributed-VCS earthquake was about to land like a truck. I used SVN in the mid-2000s and remember the relief of atomic commits the way you remember a good meal after a long flight.