Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future.
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.
It's worth having distributed version control just so you can work on your own with your own branches and crap and only bother others when you're ready to share. And so you can work seamlessly when offline.
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.
> 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.
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?
> I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future.
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.
It is distributed because everyone has a copy of the full source (nobody's copy is the copy) and you can push and pull from any machine. I can literally push from my laptop to yours (if I have an account on your machine) and you can pull from mine to yours. Github's copy of my code is exactly the same as Dave's copy. It just happens to have a fancy web interface.
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.
...so you are among the 1% who use the functionality that causes 99% of what makes git's mental model so convoluted and hard to learn (for everyone, not just the one-percenters).
That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them... Or maybe it's not as binary, and Gits model with its complexity has more useful properties making the trade off worth it.
> That does sound like the 99% are pretty dumb then for using a tool that's not suitable for them...
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.
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.