... What are the other reasons?
I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo run by Microsoft, and no one will ever use any of that distributed stuff."
They'll either laugh you out of the room or you'll be in trouble with the Department of Temporal Investigations for polluting the time line, because what we currently understand as git sure as hell won't be the design they'll come up with.
So for me: I prefer centralized. And SVN is just a reasonable one to use.
SVN feels like working in someone else's kitchen while several other people are trying to cook in it, too. It's hell. I prefer that we each have our own kitchen and bring our dishes to the table when they're ready.
I've also repeatedly found git a suitable (if not great—if they'd put all their effort behind libgit2 and make that the official implementation, that'd help a ton) tool to form the foundation of larger systems. It's a damn fine toolbox for attacking certain problems. SVN wouldn't have been much help in any of those situations.
And I thought I use git in a decentralized fashion all the time … at least I don't need to connect to any other machine when committing, switching branches, merging, rebasing, etc. And my colleagues can do the same without any network connection at the same time.
Also, while it has the biggest brand recognition, not everyone is using GitHub for all their repositories, are they?
Sure. The problem is not "distributed version control", some problems are:
- I'm on a train with no internet, finished working on a thing and want to start working on another thing and don't want to mix them up.
- I want to make a branch and don't want to wait for eons while everything gets copied on the server.
- Oops there's a problem with the server now no one can perform any work.
Yes, SVN might simple commands, but its internals are messed up. Git's UI sucks, but just learn about blobs, trees, commits, branches (pointers to commits), and you basically understand how Git works.
Tbh I'm not sure why git is called "distributed", it's a local system with remote sync capabilities.
In practice of course almost nobody uses Git to push/pull from other people's personal machines (I think I've done it once ever). But it's pretty common to push and pull from multiple hosted repos (e.g. Github and an internal company Gitlab). I imagine doing that sort of thing with SVN would be a right pain.
I actually wrote a new layer on top of Git years ago (I called it git4 IIRC) and I pitched it to both GitHub and GitLab but they ignored it.
I guess I should have pitched it to the mailing list. I think I was too afraid it was dumb. Will do that at some point.
Computing history is full of examples where technologies that are objectively not the best technologies end up being dominant. It's more about economics. (Network externalities, switching costs, ...)
Although I will admit that, with version control, there isn't even an alternative out there that is anything like an "objective winner". Each one has its problems, and it's a matter of choosing the least of the evils. -- I haven't tried any of the commercial ones though.