5 ms·

Git + Bazel will be fine for scaling up to 100s of engineers from my experience (at Lyft's L5 autonomous division). My other data point is Google, with 10,000s

Git + Bazel will be fine for scaling up to 100s of engineers from my experience (at Lyft's L5 autonomous division). My other data point is Google, with 10,000s of engineers and a bespoke VCS. I'm not sure how things work in the middle (1000s of engineers), but I think you can solve that problem when you get to it, and Bazel has some features (look at the git_repository rule) to help you split a big repo if you need to. You may also want a service like Artifactory for hosting binary blobs that feed into the build process.

qznc 6y ago
I work in a project with 50 engineers. Our git repo is 2GB plus 5GB of submodules. Git is painfully slow and I would imagine with more engineers it would become unusable. For example, git-fetch takes at least a minute. To some degree we are doing it wrong like using Windows, creating too many tags, and committing binary blobs (despite LFS). Still, scaling it up by factor of two or three would not change it significantly.
- gen220 6y ago
  Interesting... when you say fetch, are you talking about a cold-fetch? `du -sh repo` for me is 15GB, and we don't experience the slowness you describe. If I'm checking out a branch that diverged from master 1 year ago, it takes maybe... 30 seconds? But I don't know, maybe we've cast different git-spells from you all? We don't use sub-modules, for example.
  - qznc 6y ago
    I assume to some degree our Bitbucket server is slow. Not sure if Bitbucket is the culprit or our IT. One the other hand, git-status is also slow like 30 seconds. That is something I rather attribute to Windows. Doing the same inside WSL is faster. Some people invested quite some time to speed it up. So apparently it isn't some low hanging fruit.
- ptsneves 6y ago
  Have you considered making shallow clones? Also indeed you are doing many things that harm usability. I am surprised though you are saying you have issues with blobs even in LFS.
  - qznc 6y ago
    Yes. Shallow clones and submodules do not go well together though: For shallow clones, git is setup to not track all remote branches. This can result in an error message when the submodule has not fetched the commit you want to switch to.
- KerrickStaley 6y ago
  I would avoid Git submodules; it seems like a fairly poorly designed feature and I'm constantly getting my submodules into a bad state (e.g. when switching branches). The alternative that has worked a lot better for me, in repos that use Bazel, is Bazel external repositories (using git_repository or http_archive). A more direct replacement that I hear is better is git subtree although I haven't used it. Also, you're probably already doing this, but make sure you're running Git on an SSD! Spinning rust will slow down VCS workloads, which are disk intensive, considerably.
  - qznc 6y ago
    Yes, I use an SSD. Our next try is probably to rely more on Conan and Artifactory to download binary artifacts. In theory, that could result in similar behavior to Bazel cloud builds though not as integrated and granular.

qznc 6y ago

I work in a project with 50 engineers. Our git repo is 2GB plus 5GB of submodules. Git is painfully slow and I would imagine with more engineers it would become unusable. For example, git-fetch takes at least a minute. To some degree we are doing it wrong like using Windows, creating too many tags, and committing binary blobs (despite LFS). Still, scaling it up by factor of two or three would not change it significantly.

gen220 6y ago
Interesting... when you say fetch, are you talking about a cold-fetch? `du -sh repo` for me is 15GB, and we don't experience the slowness you describe. If I'm checking out a branch that diverged from master 1 year ago, it takes maybe... 30 seconds? But I don't know, maybe we've cast different git-spells from you all? We don't use sub-modules, for example.
- qznc 6y ago
  I assume to some degree our Bitbucket server is slow. Not sure if Bitbucket is the culprit or our IT. One the other hand, git-status is also slow like 30 seconds. That is something I rather attribute to Windows. Doing the same inside WSL is faster. Some people invested quite some time to speed it up. So apparently it isn't some low hanging fruit.
ptsneves 6y ago
Have you considered making shallow clones? Also indeed you are doing many things that harm usability. I am surprised though you are saying you have issues with blobs even in LFS.
- qznc 6y ago
  Yes. Shallow clones and submodules do not go well together though: For shallow clones, git is setup to not track all remote branches. This can result in an error message when the submodule has not fetched the commit you want to switch to.
KerrickStaley 6y ago
I would avoid Git submodules; it seems like a fairly poorly designed feature and I'm constantly getting my submodules into a bad state (e.g. when switching branches). The alternative that has worked a lot better for me, in repos that use Bazel, is Bazel external repositories (using git_repository or http_archive). A more direct replacement that I hear is better is git subtree although I haven't used it. Also, you're probably already doing this, but make sure you're running Git on an SSD! Spinning rust will slow down VCS workloads, which are disk intensive, considerably.
- qznc 6y ago
  Yes, I use an SSD. Our next try is probably to rely more on Conan and Artifactory to download binary artifacts. In theory, that could result in similar behavior to Bazel cloud builds though not as integrated and granular.