31–40 of 120 posts
I don't understand the isolation difference. You can hide, protect and branch code in a monorepo so why is isolation a concern?
It depends on which VCS you use. Git for example, doesn't have any native support for hiding or protecting code in particular folders within the repository.
Whats the current state of git submodules? It seems like you could get some of the benefits of mono-repos in that you can reference dependency projects directly like a mono-repo. You can, in theory, treat many projects like a single code base. I don't see it used very often though. Why not?
I regularly join projects where someone has decided to place the project's code in half a dozen different repositories. Even though it's one project. Even though they refuse to allow a release of a single component - it must all be released together without forwards/backwards compatibility. I think most of of the time, the mono/multi debate is spoiled by people who feel they can have their cake and eat it too.
I think that whether to use mono/multi repo depends on whether you're willing to dump money into updating everyting at once, or not. If not, monorepos are really a big hindrance. It's better to split on the project boundary (things that may have different development paces), and use git worktree for having different versions of libraries checked out for building/bundling. It works fairly nicely with meson, as you can…
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 clarify, one user of your library means you could stop pretending you have a library and avoid the pain.
I don't mean to insist these problems do not exist, I simply don't think many people have them.
I'm curious: how would most people here define monorepo vs multirepo? On the surface, most people seem to think of a monorepo as a source control management system that exposes all source code as if it's a traditional filesystem accessed through a single point of entry. Multirepo, in contrast, seems to be about multiple points of entry. But that's a superficial and uninteresting distinction. All the hard parts of man…
I built my engineering staff to focus on any of the initiatives that my boss hands to me (changes week/week) - so we went monorepo so we could move between those projects/apps/programs quickly.
We knew that we didn't want to pay the maintenance cost just because microservices/multirepo was a buzzword AND we wanted future ventures to get faster (example: we solved identity for authn/authz once and now every app that needs it after can leverage it and we can upgrade identity and all of its consumers in one pull request).
Earlier quoted context omitted.
At Google we check in the source of every library into the monorepo and compile them ourselves with cached builds from a central server, I don't think we use package managers.
How do you track dependencies of dependencies. Do you need to manually add the full dependency tree and re implement the dependency tracking through your internal system? If a project uses maven or gradle, you need to rewrite those files to point to your internal builds instead?
Usually somebody else has already gone through the work of doing it for you. Sometimes there are tools that do the translation for you. For example, Go modules are quite easy to translate to a BUILD file.
It’s actually not as bad as it sounds. You only have to do the hard stuff once, and every engineer in the org who uses it in the future is thankful for it.
Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it). I feel like these debates are ofte…
VCS access control are the wrong tool for solving the "people use code they shouldn't" complaint. First, VCS ACLs will massively reduce the benefits you're supposed to get from a monorepo. How will you do global refactors in that kind of a situation? How does a maintainer of a library figure out how the clients are actually using it? (The clients must have visibility into the library, but the opposite it unlikely to…
Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it). I feel like these debates are ofte…
VCS access control are the wrong tool for solving the "people use code they shouldn't" complaint. First, VCS ACLs will massively reduce the benefits you're supposed to get from a monorepo. How will you do global refactors in that kind of a situation? How does a maintainer of a library figure out how the clients are actually using it? (The clients must have visibility into the library, but the opposite it unlikely to…
I agree
> The actual solution are build system ACLs.
Or, maybe, better languages enforcing better design. In most of the cases artifacts and libraries are not related to the domain, engineers create them just to establish artificial boundaries between code components, isolate irrelated things, enforce encapsulation and avoid accidental mixing of metalanguages.
It would be lot better to have a smart compiler for this.
A tool which can prevent us from mixing different abstraction layers, creating unneccessary horizontal links between our components, etc, etc.
I have a couple of ideas how such a thing may look like.
It was introduced to counterbalance what many saw as a big mess. Result was a lot of process being introduced which slowed everything down, but that was probably necessary at that stage. To my knowledge the company keeps switching back and forth- but new projects that need to move fast typically are done independently still.
Earlier quoted context omitted.
Can you elaborate on “monorepos do not prevent you from checking packages into source control” and how that helps to avoid recompiling everything? Why would you check a package into source control anyway? Surely source control is for source code? And I lean toward monorepos, btw, but there are still lots of obstacles and monorepo proponents don’t tend to acknowledge them or offer clear suggestions for how to solve or…
You can use something like a shared binary repo such as maven or you could just check in dependencies and not worry about an external server being available for builds. >Surely source control is for source code? This is just pedantry. Checking in binaries is a pragmatic solution that solves a lot of problems.
Earlier quoted context omitted.
Can you elaborate on “monorepos do not prevent you from checking packages into source control” and how that helps to avoid recompiling everything? Why would you check a package into source control anyway? Surely source control is for source code? And I lean toward monorepos, btw, but there are still lots of obstacles and monorepo proponents don’t tend to acknowledge them or offer clear suggestions for how to solve or…
You can use something like a shared binary repo such as maven or you could just check in dependencies and not worry about an external server being available for builds. >Surely source control is for source code? This is just pedantry. Checking in binaries is a pragmatic solution that solves a lot of problems.