___ __ _____ __ ______ __
/ | / /________ / ___/____ _________ ______/ /_ /_ __/__ ____ _/ /__ ____ _
/ /| | / / ___/ __ \ \__ \/ __ \/ ___/ __ `/ ___/ __ \ / / / _ \/ __ `/ / _ \/ __ `/
/ ___ |/ (__ ) /_/ / ___/ / /_/ / / / /_/ / /__/ / / / / / / __/ /_/ / / __/ /_/ /
/_/ |_/_/____/\____/ /____/ .___/_/ \__,_/\___/_/ /_/ /_/ \___/\__,_/_/\___/\__, /
/_/ /____/
The OpenBSD developers are somewhat notorious for using CVS. No, US readers, that's not their choice of drugstore, it's their choice of source and revision control system.
Well, like many things in the OpenBSD world, it's a choice that seems to be based on the maxim "If its not broke, don't fix it". That sort of stubborn resistance to change for changes sake is a hallmark of what makes OpenBSD great. The developers care not a jot for fashion, they care that the system works, that it works reliably, in predictable ways and it does so with the maximum degree of security.
CVS (Concurrent Versioning System) was a really common tool in the FOSS world of the 1990s, incidentally when I first got involved. It seemed pretty cutting edge at the time. Certainly it offered a much better model for collaboration than either RCS (Revision Control System), which it built upon, or contemporary tools like Microsoft Visual Source Safe (a product so awful that Microsoft didn't even use it themselves).
CVS was not perfect, however. In many ways it was sort of a hack that still used RCS hidden away in its core. RCS had been designed back in 1982, and was itself essentially an improvement on the SCCS (Source Code Control System) that was developed for IBM's OS/360 in 1972. These tools weren't designed for collaboration across the Internet and certainly not at the scale that was then happening. In particular, CVS commit operations weren't truly atomic and if something went wrong, the repository could become corrupted. A painful memory for any of us that lived through it.
CVS's issues got annoying enough that the Apache Subversion project got started in aroud about the year 2000. By around 2005 a large number of projects had shifted to Subversion.
OpenBSD didn't shift though. OpenBSD kept right on using CVS. They managed it well, it did what they needed. Besides, Subversion introduces a need for repository migration, a significant number of extra dependencies and, it turns out, doesn't exactly lack issues of its own. Sure, you got atomic commits, but Subversion found it own ways to corrupt its data store, and recovering from such things was, if anything, *more* painful that recovering from CVS corruption.
So, many of us who made the jump to Subversion didn't really get a lot of benefit from that jump it seems. So perhaps the OpenBSD team get the last laugh there?
Well, perhaps.
As it turns out, Subversion's reign as the dominant source control system was short-lived (though there's still plenty of projects using it). In 2001, Thomas Lord was already working on a distributed version control system called TLA (Tom Lord's Arch).
Distributed version control made it much easier to work in the way that FOSS developers often do, and removed the reliance on a central server that some entity somewhere had to pay for and thus own. You could grab a branch directly from another developers machine and apply it locally without ever having to think about a server. A liberating experience. I remember being able to collaborate in locations without internet access. Of course we could to this before - we sent patches as diffs via emails. This was so much nicer though.
TLA would go on to spawn multiple forks including ArX, Baz and eventually GNU Arch and Canonical's Bazaar. Despite all of this excitement, this approach to source control was a little complicated for many developers who preferred the established client-server model provided by Subversion. It might have been that distributed version control systems would remain a niche, but something else was afoot.
In the late 1990s, the burgeoning success of the Linux project had created a huge amount of interest. Many companies had sprung up supporting Linux, and even giants like IBM, HP and Sun had started to get involved. The sheer number of patches that had to be reviewed, and the hierarchical system of patch submission that the kernel used, mean that many source control tools simply didn't match the required workflow, and in some case they were simply too slow to be practical.
Enter Bitmover Bitkeeper - a proprietary distributed version control system. Bitmover offered Bitkeeper to the Linux community, and other FOSS communities, free of charge, so long as they didn't work on competing source control systems. Linus Torvalds and a few of the other core developers were keen to use the system, which seemed pragmatic. Understandably, Richard Stallman, and other Free Software stalwarts like Alan Cox, had issues with this. Bitkeeper was officially adopted as the source control system for the Linux kernel in 2002, cause flame-wars and frustration. Linus was, as ever, single minded. Bitkeeper worked, it was free of charge, just suck it up.
... and so it would have remained, if it weren't for Bitmover's change of heart. In 2005. Bitmover withdrew the free-of-charge license for the Linux kernel team to use Bitkeeper. Why? Because Andrew Tridgell developed an open source tool for accessing the Bitkeeper repository, called SourcePuller. Larry McVoy, head of Bitmover, insisted he owned the repository metadata and SourcePuller was a violation of his rights, the kernel community disagreed, so Bitmover terminated the agreement.
This unsightly scuffle bought to the fore the concerns that had been present from the start. Having the worlds highest profile Open Source project rely on proprietary version control isn't a good look. Having that proprietary vendor assert ownership over some aspect of that source code was a disaster. How did Linus respond?
Git is the solution Linus came up with. With Bitkeeper yanked from under him, he wanted to keep his workflow. He needed to keep his performance. Nothing available in the free software world could do this, so he create Git a new open source distributed version control system. Linus created version 1 of git in record time. It was available in April of 2005, the same month that Bitmover yanked the Bitkeeper licenses.
Though Git is a complex beast, it was designed to support simplifying user experiences (known as porcelain). Unencumbered by proprietary licenses and costs, it was much more attractive to most F/OSS developers than Bitkeeper had ever been. Adoption beyond the Linux kernel community stared early.
Soon, people had developed web oriented git tooling that allowed it to be used in a way that simulated the client-server model of Subversion and CVS. This model was easy to understand.
With web oriented git services came an opportunity for git hosting and GitHub was founded and the snowball was rolling and gathering more snow all the time.
Today, in 2024, Git has become the de facto source control system used by nearly every software development team in the world. GitHub is the biggest source hosting site in the world, and a subsidiary of Microsoft.
... and yet OpenBSD is still developing its code with CVS.
The real hackers of this world let their code do the talking. Andrew Tridgell shook up the Linux kernel world with his code, and Linus Torvalds reacted to the resulting crisis, by coding.
This idiom applies in the OpenBSD world too. Not satisfied with CVS? No use talking about it, code a better answer.
In 2017, Stefan Sperling started a project to do just that. "Game of Trees" is an open source tool that can utilise Git repositories. It doesn't work exactly like Git, but it does allow you to work with a Git repository. Why create such a thing? Well, because it's implemented following the paradigms of the OpenBSD developer community. It is of use to its author, and maybe, just maybe, it might one day win over the OpenBSD developers in a way that plain ol' Git never could.
I'll look on with interest. 4 years in, Got is an interesting tool, and my experiments show it to be capable indeed. Will it succeed in supplanting CVS? I don't know, time will tell, but like everything in the OpenBSD world, you can go look at it, understand it fairly easily and that is in and of itself a worthwhile goal.
---
---