Git makes sense for the Linux kernel and merging patches at scale. 99% of software development would be fine with subversion
I used subversion for a long time and was resistant to moving ardour.org to use git instead. 24hours after we switched (we never use 3rd party git hosting as our canonical repo), I was already convinced it was not the right choice, but an excellent choice.
Being distributed, it solved the main gripes with SVN; it also added a better merging algorithm (https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf), solving another big gripe.
I was actually satisfied of it, and surprised that it never got attention, in particular, because there were no requirements in order to use it with existing SVN repositories. I'm actually baffled, because SVN is still active, so SVK would still be useful nowadays.
Sure, we use one canonical repository. All our “pull requests” are really merge requests, mostly to the main branch. So that’s pretty centralized, right? So why use a distributed VCS? Well, why use a local editor or IDE for code that is ultimately going to end up in the cloud somewhere? Sure, you might want to out of preference, but why should you be forced to? The fact is that wherever the code will end up is besides the point when it comes to how to develop it.
The truly important thing about distributed VCS is that it forces almost all of the operations on the repository to be usable locally. And why should it not be? What’s “git log”, “git blame”, or “git merge” got to do with whether there is one canonical repo or a hierarchy of upstreams?
I think that this idea that non-distributed VCS is somehow the default—as in the obvious, simple thing to implement—is just backwards. Of course the default assumption for any VCS operation—unless it has a name like “send-email”—should be that it operates on your own local copy.
Sure, we use a centralized repo structure. And the only call-central-command operation I use is “git push”. All the other fiddling and querying—and all the things that make version-control-as-history useful—is local.
I think there is a reason why this XKCD was made: https://xkcd.com/1597/
It will work fine over a Windows share, Samba, NFS, and so on. It doesn’t need svn or http protocol to operate.
SVN doesn't work peer-to-peer or over email. And that's fine. It's just not ready to go with only local tools.
Of course, you can use GitHub with Subversion just fine, but that wasn't the point. The point was that Subversion alone is never enough if you want to collaborate.
That’s a bummer. It would help us point the discussion in the right direction.
> SVN doesn't work peer-to-peer or over email.
Why not? What is so different about people having their own subversion repositories over file protocol vs people having their git repositories?
Why would you not be able to send a subversion patch in an email?
As someone who uses git for 10 years, I understand it may not be as ergonomic as with git. But why not?
> The point was that Subversion alone is never enough if you want to collaborate.
Why not? Is git enough?