4 ms·

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-str

by Tarean 9y ago

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?

coldtea 9y ago
>Iirc google and facebook decided against using git because it didn't scale to stupidly enormous code bases. Compared to mercurial, that Facebook uses?
- RandallBrown 9y ago
  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-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
  - snuxoll 9y ago
    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/ 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.
Yen 9y ago
> 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.

by Tarean 9y ago

coldtea 9y ago

>Iirc google and facebook decided against using git because it didn't scale to stupidly enormous code bases. Compared to mercurial, that Facebook uses?

RandallBrown 9y ago
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-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
- snuxoll 9y ago
  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/ 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.

Yen 9y ago

> 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.