3 ms·
There is no better, there is only tradeoffs, and some people prefer one tradeoff and others prefer another tradeoff. That's just how it is. So before making an
by erikb 9y ago
There is no better, there is only tradeoffs, and some people prefer one tradeoff and others prefer another tradeoff. That's just how it is.
So before making any siginficant changes one should discuss what the desired tradeoff is, and then measure the continuous change towards that tradeoff.
For instance monorepo is a goal for people who want interacting tools to be build in their corresponding state without need to consult someone else. Can you do that? Check out the repo (for 2-5 hours depending on your code size) and then just hit "make" and "make test" and it runs through? If yes it's a success, if no something went wrong in the process.
PS: There are actually build tools that are language independent, e.g. make, CMake or Maven. You can just use these.
PPS: I'm personally really happy to see that monorepo in itself doesn't resolve the dependency tracking for internal tools. I still believe in the other way around. A good dependency tracking tool can totally replace monorepos.
- the_af 9y ago> PS: There are actually build tools that are language independent, e.g. make, CMake or Maven. You can just use these. This is technically true, but I wouldn't inflict on myself and my team the use of Maven if I wasn't using Java or a related language. Some language ecosystems come with a preferred or natural build system (and related tools), and it's weird to use something else within that ecosystem, or to use standard but cumbersome tools (such as Maven) outside their ecosystem. It's possible in practice, but weird.
- robrenaud 9y agoAt Google, which is mostly a very large mono-repo (Android/Chrome being exceptions), I can get my own writable copy of the entire code base in about 3 seconds.
- erikb 9y agoThey don't use git, right?
- dfabulich 9y ago(Author here.) I agree with your main point but wanted to respond to your PS. I think it's important to distinguish build tools like make from declarative versioned-dependency management tools, which multirepos require. For example, you can build a multi-language monorepo with either make or CMake, but you can't declare that your repo builds "foo" version 1.2.3 and that it depends on "bar" version 2.3.4. Maven does that, and it will automatically download the right version of bar for you and make it available, but Maven doesn't work well for C# dlls. You can use NuGet for dlls, but don't try it with JS modules. Use npm to manage JS modules, but don't try it with Perl packages. You can use CPAN for Perl packages, etc.
- erikb 9y agoAgreed. Make+Monorepo possible. Make+Multirepo maybe not enough.