Care to highlight what issues you've had with their CVS system?
Also, git on the server seems to use less resources (which is one of the reasons git "won")
OpenBSD has been traditionally anti-branch.
Theo de Raadt's 2009 presentation: https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
Ted Unangst's blog, email: http://www.tedunangst.com/flak/post/branchless-development https://marc.info/?l=openbsd-misc&m=134419365218558&w=2
Basically, it's to make all OpenBSD developers participate in the release process. There's no dev and stable team - everyone is in the same tree, makes breaking changes early, spends months stabilizing. CVS helps force developers to participate, because branches can't exist for long before the resulting merge is too painful to be worth it.
Although, they are careful to say that, just because it works for them, doesn't mean it will work for you. As well, your other points are still valid. (My personal gripe is that CVS over the net is so slow that I have to use an external tool like CVSync.)
You're reversing the causes and consequences.
Git was awesome from the start, and asn an over-night success due to linux.
Github's contribution, and role in git's success, was only one: providing a free hosting service that presented a usable and user-friendly alternative to sourceforge.
There are plenty of hosting companies that support Git, and some even supported competing decentralized version control systems from the start. Yet, none of them worked so well as git.
When github arrived, git's biggest win was the kernel. But that was kinda a given if you consider its genesis. Granted, it's a noteworthy project that helps prove git's scaling capability. But IMO git didn't win until years later when folks who had adopted the other DVCS engines started switching to git.
Two things were decisive: being able to commit and browse the whole history while offline and the fact that my main dev machine was Linux so it worked faster than anything else.
But bzr always had the ability to read and write repositories written using older formats. Each on-disk repository format is implemented as a set of separate Python classes, all exposing the same interface.
Git thought it could do without a "repository format version identifier" and a strategy for multiple on-disk formats until version 2.7 (2015). Bzr had everything well planned out since the beginning.
Jokes aside, github won because - unlike sourceforge and gitorious - their web interface did not suck.