Monorepos: Please don’t • Hacker News Board

Re: Monorepos: Please don’t

#51

Post by titzer » Thu, Jan 03, 2019, 5:34 AM UTC

No silver bullet here, I think.

It's definitely the case that a mega monorepo doesn't, in practice, have the atomic commit property. E.g. once you add owner files and separate code reviews, you're in for a world of hurt. Case in point, Google developed an internal tool to split cross-cutting CLs into manageable pieces, wrangle all the owners and approvals, presubmits, etc, and then submit the CL piecemeal--i.e. not atomic.

Chromium uses a different model. It just DEPS's in other repos at pinned versions. That has a whole other set of problems.

Re: Monorepos: Please don’t

#52

Post by 0xFACEFEED » Thu, Jan 03, 2019, 5:38 AM UTC

At least the author gave us the courtesy of italicizing his broken assumption from the outset of the post.

> Because, at scale, a monorepo must solve every problem that a polyrepo must solve, with the downside of encouraging tight coupling, and the additional herculean effort of tackling VCS scalability.

Right.

But you have to get to "scale" first (as it relates to VCSs). Most companies don't. Even if they're successful. Introducing polyrepos front loads the scaling problems for no reason whatsoever. A giant waste of time.

Checkmate! I didn't even need a snarky poll. The irony of that poll is that it clearly demonstrates his zealotry, not other people's.

Re: Monorepos: Please don’t

#53

Post by maktouch » Thu, Jan 03, 2019, 5:41 AM UTC

Mxtetris wrote: post #45

WorldMaker wrote: post #16

Earlier 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...

With Phabricator, yes, you can setup herald rules that stops a merge from happening if a file has changed in a specific subdir.

We use service owners, so when a change spans multiple services, they are all added automatically as blocking reviewers.

Re: Monorepos: Please don’t

#54

Post by peterwwillis » Thu, Jan 03, 2019, 5:45 AM UTC

"The frank reality is that, at scale, how well an organization does with code sharing, collaboration, tight coupling, etc. is a direct result of engineering culture and leadership, and has nothing to do with whether a monorepo or a polyrepo is used. The two solutions end up looking identical to the developer. In the face of this, why use a monorepo in the first place?"

.....because, as the author directly stated, the type of repo has nothing to do with the product being successful. So stop bikeshedding, pick a model, and get on with the real business of delivering a successful product.

Re: Monorepos: Please don’t

#55

Post by shereadsthenews » Thu, Jan 03, 2019, 5:49 AM UTC

This argument boils down to people who have used Perforce, who believe in the benefits of a monorepo, and people who have only ever used git, who do not. While it's true that git is a terrible program that does not lead to conclusions about the merits of a monorepo.

Re: Monorepos: Please don’t

#56

Post by clhodapp » Thu, Jan 03, 2019, 5:55 AM UTC

naniwaduni wrote: post #34

curtis wrote: post #32

My 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…

> As a final observation, you can split big repositories into smaller ones quite easily (in Git anyway) but sticking small repositories together into a bigger one is a lot harder. So start out with a monorepo and only split smaller repositories out when it's clear that it really makes sense. If you only need to do this once, subtree will do the job, even retaining all your history if you want. I'm not sure what the e…

To split, you can duplicate the repo and pull trees out of each dupe in normal commits.

Re: Monorepos: Please don’t

#57

Post by garmaine » Thu, Jan 03, 2019, 6:02 AM UTC

young_unixer wrote: post #43

erikpukinskis wrote: post #40

Earlier quoted context omitted.

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.

“For a longer explanation: see this Medium post.”

There is a certain irony there which betrays one of the problems left unaddressed.

Re: Monorepos: Please don’t

#58

Post by karmakaze » Thu, Jan 03, 2019, 6:03 AM UTC

TL;DR

The post just reads like some opinionated piece for traffic. The author has never even used a monorepo as far as I can tell, so can only argue from one side, the best one ever used: polyrepo. Then goes on to list 'theoretical' benefits and the downsides (which should also be theoretical if having never been used) of monorepos. It concludes with "The two solutions end up looking identical to the developer. In the face of this, why use a monorepo in the first place? Please don’t!" implying that 'Google, Facebook, Twitter, and others' do it for no benefit.

Re: Monorepos: Please don’t

#59

Post by 01100011 » Thu, Jan 03, 2019, 6:04 AM UTC

sfrench wrote: post #44

My 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 coordi…

Jesus, this. Look, you're going to run into issues either way, because you're trying to solve a difficult problem.

It's like thinking OOP or functional programming is going to solve all your issues... I mean, in some limited cases they could, but realistically you're just smooshing the difficulties around and hopefully moving them to somewhere where you are more able to deal with them.

FWIW, I've worked in a many-repo org and it sucked worse than huge companies with monorepos and good tooling, but I'm not going to make some blanket statement because it depends on the specifics of your code/release process/developer familiarity etc.

Re: Monorepos: Please don’t

#60

Post by wtracy » Thu, Jan 03, 2019, 6:07 AM UTC

I'm not familiar with how monorepos work in practice, but it seems obvious to me that it's going to complicate everyday tasks.

Ready to commit? Whoops, another team made a bunch of commits to their project, and you need to rebase your project before you can commit. (I'm having flashbacks to Clearcase already.)

Need to roll back the last two commits you made? Sure, that takes two seconds--oh, wait, another team made multiple commits that got interleaved with yours. Have fun cherry picking the files you want to revert.

Of course, I'm apparently a curmodgeon, because as soon as someone starts talking about running a find/replace globally across multiple projects, I want to grab something sharp.