What do you think is more possible?

(a) the result of the work of a major Git player like GitHub, and a major software company like Microsoft, with tens of excellent engineers devoted on it, and that solves a real pain point they have, is a centralized abomination that merely replicates a feature SVN already had

(b) your description is a crude knee jerk reaction

?

In a similar rhetorical style:

If SVN is a terrible application with no merits to large developers like MS, why did it exist in the first place?

If the features SVN brings over git are not considered detrimental by Torvalds, why did he create his own VCS with them removed, and why hasn't he added them back in?

>If SVN is a terrible application with no merits to large developers like MS, why did it exist in the first place?

Where's the contradiction? All kids of terrible apps exist. Terribleness and existence are not mutually exclusive qualities.

(Assuming SVN is terrible, of course, which I didn't say. I'd say SVN was a attempt to go beyond CVS with some shortcomings that don't make it the best available option today).

>If the features SVN brings over git are not considered detrimental by Torvalds, why did he create his own VCS with them removed, and why hasn't he added them back in?

Lots of possible answers (given the assumption in your "if"):

E.g. he might not consider them detrimental for other people and use cases, but he doesn't need them for his use case (Linux kernel development) either.

Or he thinks that while they might be good, they complicate things too much, and he prefers a more minimum feature set.

Iirc google and facebook decided against using git because it didn't scale to stupidly enormous code bases.

Microsoft decided to stick with git but add non-strict fetching to it. On the plus side, still all the advantages of easy branching/merging and working offline if you touched the required files which distributed vcs's bring. But you still need to be connected to work with parts of the code base you haven't used before.

So I guess if you run the test suite for your current task first then you can work offline since all relevant files will be fetched?

> But you still need to be connected to work with parts of the code base you haven't used before.

Which seems like a fair tradeoff to me. The existing "native solution" for a very very large codebase would be to have it split into multiple, logical repositories. If you fetched one repo you needed to work on, but not all the dependencies or sibling repos, you still wouldn't be able to work on those other parts of the codebase until you connected.

>Iirc google and facebook decided against using git because it didn't scale to stupidly enormous code bases.

Compared to mercurial, that Facebook uses?

And Facebook added a lot to Mercurial so that it would scale to their stupidly enormous code base.

https://code.facebook.com/posts/218678814984400/scaling-merc...

Meanwhile OpenJDK (which is another project composed of separate but interconnected components) wrote a mercurial extension to manage multiple repositories easily (http://openjdk.java.net/projects/code-tools/trees/). I think this is a much better solution than a monorepo, you can still see the "whole codebase" like it were a single giant repository but you don't have to deal with the scaling headaches in quite the same way.

I was pretty surprised when I made my own build of OpenJDK 9 how easy it was to work with, `hg tclone blah`, `hg tup jdk9.0.1+11`, `./configure blah; make images` and done. Even if git submodules were closer in functionality (checking out the same tag across multiple modules at once with ease) the song-and-dance with actually downloading the modules after cloning is annoying.

It's still distributed, just not entirely 100% distributed. It's like the difference in which IPFS nodes have which items pinned or how many seeders you have versus torrenters (and the subsequent file availability in that cluster) in BitTorrent.

Are these things really comparable? I am not so sure. My understanding of GVFS is that it is hierarchical, not P2P.

In the reference implementation from Microsoft it most closely resembles a CDN: you give it a list of servers to back the git database when it needs to look up an object. You distribute those servers as you see need to, based on very similar logic to CDN distribution. For instance, you probably want at least one available per office to keep content close to the users that need it.

Even if a CDN is more "hierarchical" rather than P2P, it's still distributed, it's just distributed on a different axis than you are perhaps expecting.

Furthermore, to a very large extent that's an implementation detail. The GVFS protocol itself [1] is a very simple REST API, and there is absolutely nothing stopping you from building a GVFS "server" that is literally backed by IPFS or BitTorrent or some other P2P file system.

[1] https://github.com/Microsoft/gvfs/blob/master/Protocol.md