Static analysis is easier on monorepo. At least one can run it on all code. Polyrepo has the problem that some code is off the radar. That might be the only advantage of monorepo in my opinion.
Monorepos: Please don’t
41–50 of 402 posts
Re: Monorepos: Please don’t
#42Earlier quoted context omitted.
It's an interesting social problem in how you manage those project / library / repository boundaries. On the flipside, though, it's been well documented that among many of the major monorepos those boundaries still exist, they just become far more opaque because no one has to track them. You find the weird gatekeepers in the dark that spring out only when you get late in your code review process because you touched "…
http://wiki.c2.com/?ConwaysLaw "Conway's Law" is something like "organisation of code will match the organisation of people". It's a neat description. I think it's more common to merge or split modules and classes than repositories. I wonder if there'd be less tension if repos and teams were 1:1 though.
> I wonder if there'd be less tension if repos and teams were 1:1 though
Anecdotally, yes I think it helps a lot. I was once part of an organization for which each "team" having a repo is the only thing that prevented violence :-)
Re: Monorepos: Please don’t
#43I agree, but also... Medium: Please don't
Why?
TL;DR: Really bad user experience.
For a longer explanation see https://medium.com/@nikitonsky/medium-is-a-poor-choice-for-b...
Alternatives better than medium: Wordpress, Blogger, github pages, plain html files.
Re: Monorepos: Please don’t
#44My last 2 jobs have been working on developer productivity for 100+ developer organizations. One is a monorepo, one is not. Neither really seems to result in less work, or a better experience. But I've found that your choice just dictates what type of problems you have to solve.
Monorepos are going to be mostly challenges around scaling the org in a single repo.
Polyrepos are going to be mostly challenges with coordination.
But the absolute worst thing to do is not commit to a course of action and have to solve both sets of challenges (eg: having one pretty big repo with 80% of your code, and then the other 20% in a series of smaller repos)
Re: Monorepos: Please don’t
#45My problem with polyrepos is that often organizations end up splitting things too finely, and now I'm unable to make a single commit to introduce a feature because my changes have to live across several repositories. Which makes code review more annoying because you have to tab back and forth to see all the context. It's doubly frustrating when I'm (or my team is) the only people working on those repositories, becaus…
It's an interesting social problem in how you manage those project / library / repository boundaries. On the flipside, though, it's been well documented that among many of the major monorepos those boundaries still exist, they just become far more opaque because no one has to track them. You find the weird gatekeepers in the dark that spring out only when you get late in your code review process because you touched "…
Can a monorepo support module- or subdirectory-level ownership controls? Or do teams using a monorepo just do without them?
Partially answering my own question: SVN, recommended in a prior comment [0], supports path-based authorization [1]. But what about teams using another version control system?
[0] https://news.ycombinator.com/item?id=18810313
[1] http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverc...
Re: Monorepos: Please don’t
#46>Scaling a single VCS to hundreds of developers, hundreds of millions lines of code...
Maybe I am way out of my element here, but is this a common problem? Do companies with only “hundreds of engineers” really have “hundreds of millions of lines of code”?
Re: Monorepos: Please don’t
#47My advice is that if components need to release together, then they ought to be in the same repo. I'd probably go further and say that if you just think components might need to release together then they should go in the same repo, because you can in fact pretty easily manage projects with different release schedules from the same repo if you really need to. On the other hand if you've got a whole bunch of component…
After trying to get the best of both with Subversion Externals and Git Submodules, I'd have to agree. At least until things are so loosely coupled they're begging for a public release.
That said, some packaging solutions can bridge the gap reasonably well. Unless you need instantaneous, atomic releases.
Re: Monorepos: Please don’t
#48>Scaling a single VCS to hundreds of developers, hundreds of millions lines of code... Maybe I am way out of my element here, but is this a common problem? Do companies with only “hundreds of engineers” really have “hundreds of millions of lines of code”?
From personal experience, it can happen. At one point, I was personally responsible for about 2 million lines of code. Over several years, I was able to reduce it to about 500k through generous use of code generation for ORM type work. The generated code never ended up in VCS, but the generator and model did. Certainly helped checkout/update times as there was several thousand fewer files to deal with.
I was one of about 900 engineers at a financial company of about 1500 employees at the time.
I don't honestly know how many lines of code there were across the company, but I imagine it easily exceeded 100M. It took us a full week to do a full recompile of everything. We had no CI... Was always a problem approaching release time.
Re: Monorepos: Please don’t
#49I’ve found monorepos to be extremely valuable in an immature, high-churn codebase. Need to change a function signature or interface? Cool, global find & replace. At some point monorepos outgrow their usefulness. The sheer amount of files in something that’s 10K+ LOC ( not that large, I know ) warrants breaking apart the codebase into packages. Still, I almost err on the side of monorepos because of the convenience th…
Monorepos and packages are not mutually exclusive. You can and should have many different projects in subfolders I'm your monorepo, each with their own builds and tests and artifacts (though hopefully somewhat standardized). The point is that now it's easy to release changes across multiple projects, integration test between them on a specific global patch, etc, without a whole pile of complex tooling.
Re: Monorepos: Please don’t
#50Earlier quoted context omitted.
It's an interesting social problem in how you manage those project / library / repository boundaries. On the flipside, though, it's been well documented that among many of the major monorepos those boundaries still exist, they just become far more opaque because no one has to track them. You find the weird gatekeepers in the dark that spring out only when you get late in your code review process because you touched "…
Can a monorepo support module- or subdirectory-level ownership controls? Or do teams using a monorepo just do without them? Partially answering my own question: SVN, recommended in a prior comment [0], supports path-based authorization [1]. But what about teams using another version control system? [0] https://news.ycombinator.com/item?id=18810313 [1] http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverc...
SVN allows for you to create mutliple repos within a repo. (That's probably why the path based auth works).
Git has the idea of sub-modules, but they're really just filters. (They're in the same repo). So ultimately, you don't have that kind of control.