forrestthewoodsHere is my best attempt to articulate why I believe all dependencies, including compiler toolchains, belong in version control.
https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/
Bart Wronski 🇺🇦🇵🇸@forrestthewoods @mtothevizzah as you pointed out, your dream VCS exists (more than once?). Google monorepo + VFS + VCS is exactly like that. Everything checked in from LLVM through libraries to your project, everything passing tests, everything building, everything updated to the same version (so you don't end up with 10 libraries using 10 versions of Eigen or whatever).
I absolutely loved it. :)
Oh, and I obviously also strongly agree with all your post's points. This is the only sane way.
@BartWronski @mtothevizzah yeah Meta is the same way. But with Buck and a custom Mercurial. It really is The Way.
If only the tooling were more accessible to the outside world!
@forrestthewoods @mtothevizzah Google open sources bits and pieces (Bazel). I think they would like to open source more, but a huge chunk of "magic" of how well it works is in tight integration with their infrastructure, build servers, IT, DevOps - a huge machinery with no magic single component but requiring all to run in tandem. Any single component would be just "ok" and nerfed for a standalone open source release...
@BartWronski @mtothevizzah there’s definitely a “more than the sum of its parts” aspect. Bazel/Buck both work in the wild. But the monorepo is missing which is effectively what I’m arguing should exist in the public sphere.
Build cache, build farm, CI systems etc are another layer. But I think there’d be value in “Perforce but sucks less and is broadly available”