A tool like git could make operations such as branching and merging easier, and allowing developers to collaborate more. It also has a global revision identifier (instead of file based revisions) and signed commits which may increase security.
Also, git on the server seems to use less resources (which is one of the reasons git "won")
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.)
> IMO git won due to github more than anything else.
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.
I disagree. Github arrived in 2008, soon after many DVCS options arrived. Mercurial and git were developed at very near the same time in 2005, Bazaar was developed around then too. I don't believe that git had anywhere near the market share back in 2008 that it enjoys now.
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.
Don't know about the rest, but I switched from SVN to git before I even heard of Github for my personal project and also in the company I was CTO at the time.
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.
And git won because hands down it was the fastest and most flexible, albeit most horrible UX. Also unlike something like say bzr, the core on disk git format has stayed relatively unchanged since it was first written. The architecture is simply the best in git compared to most other vcs software.
Actually, there was one big disk format change early in git history: the object id changed from the SHA1 of the compressed object to the SHA1 of the uncompressed object. All three projects using git back then (Linux, sparse, and git itself) had to convert to the new format (since the object ids changed, every tree and commit object had to be rewritten).
> Sure, and I said relatively unchanged compared to bzr. Looking up in bzr, the ondisk format changed several times in incompatible ways.
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.
Also, git on the server seems to use less resources (which is one of the reasons git "won")