4 ms·

I think its less maintenance and more for pinning versions of software to ensure stability. I guess that comes with maintaining a package manager like apt. Def

I think its less maintenance and more for pinning versions of software to ensure stability. I guess that comes with maintaining a package manager like apt. Definitely with you on not realizing it was a joke at first. Don't google have a company wide mono repo, that I'd guess includes all search and chrome? Or is that just an urban legend?

samus 3y ago
The stuff in Google's monorepo is mostly their own code, not snapshots from upstream.
- bluGill 3y ago
  Chrome has brought in third party code. Which makes Debian mad and they do a lot of work to strip that out to use the upstream libraries. (Or at least that is how I understand it - I don't follow Debian closely)
  - samus 3y ago
    Yeah, that's why I wrote "mostly" :)
- tetromino_ 3y ago
  Google's monorepo includes snapshots of everything upstream that Google's proprietary code depends on - starting from the kernel and glibc and core language toolchains, and all the way up to various open-source libraries and modules in c/python/java/whatever.
  - riku_iki 3y ago
    But 3p sources likely are for specific stable version? Linus can't break Google by submitting bug into linux kernel?
    - tetromino_ 3y ago
      Yes.
WanderPanda 3y ago
Isn‘t git submodules a much more lean way at accomplishing this than a clunky 500gb repo?
wongarsu 3y ago
Doesn't google have a lot of internal tooling to make that monorepo actually work for them? The issue isn't so much that large monorepos don't work, it's that you are trading one set of issues for another set of issues. And most popular open source tooling (and I assume all debian-specific tooling) is built around solving the issues of many repositories rather than solving the issues of monorepos.
- riku_iki 3y ago
  > Doesn't google have a lot of internal tooling to make that monorepo actually work for them? probably tests coverage and workflow matters: you can work with monorepo if you can check how your change will impact rest of the ecosystem.
  - wongarsu 3y ago
    At its core, with separate repositories it's generally fine to pretend that any commit effects all code within that repo. So for example you might run all unit tests for every new commit in a PR, or run all deploy scripts when something is committed to master. Dependencies are usually set up one-way, so code pulls it its dependencies (by referencing specific git commits or released packages). So a change in one repository might mean that it pulls in new or updated dependencies, but software depending on you should only see changes once a change is made to its repository. For a monorepo those assumption don't hold, any given commit likely only affects a tiny fraction of the content of the monorepo. But a change in a library might also immediately radiate outward to anything in that repo that uses the library, so you can't do a naive check based on the directory tree. So you end up with a build system like bazel that can evaluate the entire dependency graph to know what to run. And you have to do that for pretty much all tooling you want to be triggered by code changes. Add on top of that the scaling issues you have with git as your repository grows
  - deleted 3y ago
    [deleted]
- ants_everywhere 3y ago
  yes, and a lot of it's open source. The main issue IMHO is that git doesn't scale for a monorepo. A monorepo wants to spread a single virtual repo over a large number of devices, with no device having the entire repo. In contrast, git wants to do the opposite: it's built for a large number of devices to have the same copy of the entire repo. But aside from tooling and needing a horizontally scalable VCS, there's also the cost and engineering resources required to keep the cluster running, available, and high performance.
Tyr42 3y ago
I think chrome is got its own thing if I remember from my internship. But almost everything in one repo sounds right.

samus 3y ago

The stuff in Google's monorepo is mostly their own code, not snapshots from upstream.

bluGill 3y ago
Chrome has brought in third party code. Which makes Debian mad and they do a lot of work to strip that out to use the upstream libraries. (Or at least that is how I understand it - I don't follow Debian closely)
- samus 3y ago
  Yeah, that's why I wrote "mostly" :)
tetromino_ 3y ago
Google's monorepo includes snapshots of everything upstream that Google's proprietary code depends on - starting from the kernel and glibc and core language toolchains, and all the way up to various open-source libraries and modules in c/python/java/whatever.
- riku_iki 3y ago
  But 3p sources likely are for specific stable version? Linus can't break Google by submitting bug into linux kernel?
  - tetromino_ 3y ago
    Yes.

WanderPanda 3y ago

Isn‘t git submodules a much more lean way at accomplishing this than a clunky 500gb repo?

wongarsu 3y ago

Doesn't google have a lot of internal tooling to make that monorepo actually work for them? The issue isn't so much that large monorepos don't work, it's that you are trading one set of issues for another set of issues. And most popular open source tooling (and I assume all debian-specific tooling) is built around solving the issues of many repositories rather than solving the issues of monorepos.

riku_iki 3y ago
> Doesn't google have a lot of internal tooling to make that monorepo actually work for them? probably tests coverage and workflow matters: you can work with monorepo if you can check how your change will impact rest of the ecosystem.
- wongarsu 3y ago
  At its core, with separate repositories it's generally fine to pretend that any commit effects all code within that repo. So for example you might run all unit tests for every new commit in a PR, or run all deploy scripts when something is committed to master. Dependencies are usually set up one-way, so code pulls it its dependencies (by referencing specific git commits or released packages). So a change in one repository might mean that it pulls in new or updated dependencies, but software depending on you should only see changes once a change is made to its repository. For a monorepo those assumption don't hold, any given commit likely only affects a tiny fraction of the content of the monorepo. But a change in a library might also immediately radiate outward to anything in that repo that uses the library, so you can't do a naive check based on the directory tree. So you end up with a build system like bazel that can evaluate the entire dependency graph to know what to run. And you have to do that for pretty much all tooling you want to be triggered by code changes. Add on top of that the scaling issues you have with git as your repository grows
- deleted 3y ago
  [deleted]
ants_everywhere 3y ago
yes, and a lot of it's open source. The main issue IMHO is that git doesn't scale for a monorepo. A monorepo wants to spread a single virtual repo over a large number of devices, with no device having the entire repo. In contrast, git wants to do the opposite: it's built for a large number of devices to have the same copy of the entire repo. But aside from tooling and needing a horizontally scalable VCS, there's also the cost and engineering resources required to keep the cluster running, available, and high performance.

Tyr42 3y ago

I think chrome is got its own thing if I remember from my internship. But almost everything in one repo sounds right.