It misses out BitKeeper, which inspired both Git and Mercurial, which was launched 5 years earlier.
That would include BitKeeper --- copies were available for a few years at no cost to Linux kernel developers, but only on increasingly restrictive terms, which McVoy ultimately wound up revoking altogether. IIRC, Linus released the first embryonic version of git within weeks after McVoy withdrew the free-as-in-beer version of BitKeeper.
People often complain about the idea of using version control for large binary files, as if it is unreasonable to want such a thing, and that as a point of principle version control systems should contain only text files, and the fact that many version control systems support this poorly is proof that you don't want it anyway. But there are actually people who create, with their own hands, large binary files, often of the completely-unmergeable variety, and they deserve version control just as much as the programmers do.
(And then once you have a system that works well for them, you can then use it to solve all manner of problems that might previously have involved storing files in public folders, mailing them round, or maybe just waiting for them to compile again. No need for any of that crap any more - just check the files in, they're there forever, and you can get them back quickly.)
It is, in the sense that a decentralized VCS is, essentially, a superset of a centralized one.
…
Blobs are certainly still an issue, though orthogonal to distribution (I don't think you intended to imply it was related, but it could be read as if you did).
Distributed systems rely on allowing people to (in effect) create multiple versions of the same file, and then merge them all together later. But it's very rare that binary files are mergeable! And if the file can't be merged, the distributed approach won't work. People will step on one another's changes by accident, and people will have to redo work.
The usual solution is simply not to allow multiple versions to exist: enforce some kind of locking system, so that each editor has to commit their changes before the next one can have a go. But now you need some centralized place to store the locking information...
I think that the GP used the phrase correctly, but not being a native English speaker myself, I'm not entirely sure.
The resulting debacle was fairly ridiculous; Linux chastising Andrew Tridgell, continued flamewars about using a closed-source product.
What I find interesting here, though, is just how much hot water McVoy landed in. He gave away free licenses to Linux developers, then when someone in that community started reverse engineering his product with the intent to replace it, he revoked the free license, leading Linus to develop a replacement anyway -- one that has largely consumed the vast majority of BitKeeper's target market.
But the author addresses the point anyway: > I’m not recording the first time anyone made the astonishing thing, but the first time it was productised and became popular.
But that said, git really isn't very similar to bitkeeper except insofar as it enables distributed development. Both model development as a forest of independent developer trees which communicate with each other through merges. But bitkeeper is still a traditional centralized server keeping a bunch of delta'd files.
The decision bitkeeper made to keep files in SCCS format was of course not revolutionary, but tells you quite a bit about the target market (people who had makefiles that relied on implicit commands like get just working). They went to extra effort to make it look just a bunch of delta'd files.
[1] http://en.wikipedia.org/wiki/Monotone_(software)#Monotone_as...