Monorepo or Multirepo? Role-Based Repositories

Post by djhaskin987 » Sat, Oct 12, 2019, 9:17 PM UTC

username90 wrote: post #25

dmoy wrote: post #22

Earlier quoted context omitted.

At large enough scale, it causes a lot of problems and breaks like every other dev tool requiring a lot of work to get it back together. That said, there are some open source pieces to help. Facebook open sourced their mercurial stuffs so you can get version control at scale (and before then you just use perforce). Google open sourced bazel. Google open sourced some parts of the underlying infra behind code search, b…

It is just that Googles tooling around code works really well together. Code search to view code and directory based history so you aren't swamped by others commits, tap to run all unit tests all the time but with sectioned projects so you don't run all tests on every presubmit, sponge to gather every test log ever (even for the tests you run locally) so you can link full test logs to coworkers when you have problems…

Post by pshirshov » Sat, Oct 12, 2019, 10:09 PM UTC

jyounker wrote: post #57

pshirshov wrote: post #41

Earlier quoted context omitted.

> Monorepo shortcomings 1 and 2 seem like bullshit to me. It's a blogpost and the author didn't try to build a total and exhaustive formal system. These shortcomings are not absolute truth but actually they are true. I've seen this multiple times: a small projects evolves over years into a monster. Engineers add new components and reuse any other components they may need creating horizontal links. At some point they…

Monorepo/multirepo and monolith/microservice are orthogonal concepts. When organizations don't understand that then they may end up building a distributed monolith in across multiple repos. (The "Distributed Big Ball of Mud" anti-pattern.) Monorepo advocates are typically advocating for microservices, but within a single code base. The way you provide access control is through code review and build system visibility.…

Post by marcinzm » Sat, Oct 12, 2019, 10:16 PM UTC

weberc2 wrote: post #49

jayd16 wrote: post #43

Earlier quoted context omitted.

In short, the binaries are already built. Usually its faster to link to a prebuilt binary than to build from scratch.

So where do these binaries get built and how does the system know which binaries to rebuild for a given change? If developers are building binaries and committing them directly, doesn’t that open up security or even correctness issues? How does this approach satisfy compliance concerns (how can the CTO or a manager sign off on the changes that went into the binary if it’s just something a random developer committed?)…

Post by [deleted] » Sat, Oct 12, 2019, 10:43 PM UTC

user5994461 wrote: post #62

chrisseaton wrote: post #7

Earlier quoted context omitted.

I think they do, but there is only ever one single version in use - the version in the repo.

If so, they would have a massive problem upgrading libraries like numpy because there are too many and too big breaking changes between releases.

Post by pricechild » Sat, Oct 12, 2019, 10:52 PM UTC

megous wrote: post #50

pricechild wrote: post #33

Earlier quoted context omitted.

> whether you're willing to dump money into updating everyting at once I think the majority of projects in this world only update everything at once. They haven't investing in testing, sensible api's and testing to allow updating small pieces of their solution. From my experience, I also think the majority of people who think they have a library and need multi repos to deal with that, don't have a library. To further…

Project != company. Project != consultancy. Monorepo just didn't work for me. I have ~10 web projects for different customers + my personal projects that use various versions of some common code. It doesn't make any financial sense to evolve my common code by updating all the customer's code for free when they're not even asking for it. So on this level it doesn't work. Even within a single company with just two devs…