Monorepos: Please don’t • Hacker News Board

Re: Monorepos: Please don’t

#141

Post by tigershark » Thu, Jan 03, 2019, 9:54 AM UTC

forty wrote: post #113

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…

My rule of thumb is: if you need to do PRs in several repositories to do one features, you should probably merge the repositories. At work, we have code spread among a bunch of repositories, and having to link to the 2/3 related PRs in other repos is a major PITA, and even more so for the reviewers.

Not always. It makes absolutely sense to have a repository for the gui and one for the server. When writing a new feature you usually write some gui code and some server code and create different pull requests. I think monorepos are seriously wrong and I completely agree with this article.

Re: Monorepos: Please don’t

#142

Post by floatboth » Thu, Jan 03, 2019, 9:54 AM UTC

nomel wrote: post #8

pbiggar wrote: post #5

Alternate title: monorepos - ideal for teams under 100 devs

The title should have been "Monorepos: Please don't, at scale", but I suspect it was made intentionally controversial.

If it's not at scale, is it even a monorepo? It's just… repo??

Re: Monorepos: Please don’t

#143

Post by rkangel » Thu, Jan 03, 2019, 9:55 AM UTC

joeblau wrote: post #10

pbiggar wrote: post #5

Alternate title: monorepos - ideal for teams under 100 devs

At Uber, both of our iOS and Android teams are over 100 contributors each and we have a Monorepo for each app platform. I'm not on the ops team but being in a Monorepo here has been one of the best development experiences in my career.

> we have a Monorepo for each app platform

Do you mean two separate mono-repos, one for Android, one for iOS? To me that's not a monorepo. Is there little shared code between the two platforms, or is there a third repo that is depended on?

Re: Monorepos: Please don’t

#144

Post by rkangel » Thu, Jan 03, 2019, 9:58 AM UTC

To me, the key point is this: Splitting your code into multiple repos draws a permanent architectural boundary, and it's done at the start of a project (when you know the least about the right solution).

The upsides and downsides of this are an interesting debate, but there is a cost to polyrepos if you want to change the system architecture. There is a cost to monorepos too as argued by this post, and its up to the tech leads as to which cost is greater.

Re: Monorepos: Please don’t

#145

Post by andy_ppp » Thu, Jan 03, 2019, 9:59 AM UTC

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…

What are you talking about! In my perfect micro services world I just have these enforced bounded contexts that are so perfectly designed they never need to change. Consequently all parts of the system are perfectly independent snowflakes that can be deployed without thinking about any other parts of the system. It’s beautiful really when you think about the mess that things were before we could do this!

Re: Monorepos: Please don’t

#146

Post by lclarkmichalek » Thu, Jan 03, 2019, 9:59 AM UTC

sbr464 wrote: post #134

One glaring omission of the monorepo design, not sure why really, is if you want open and closed source software in the same monorepo, it doesn’t seem possible. Curious as to why this design choice was made.

It's entirely possible, and repositories like https://github.com/facebook/fbthrift/ are an example of an open source project that is synced commit for commit with a private monorepo.

It just requires some tooling (like everything with monorepos)

Re: Monorepos: Please don’t

#147

Post by hvidgaard » Thu, Jan 03, 2019, 10:00 AM UTC

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…

I haven't tried in Git, but with Mercurial merging repos is as simple as pulling from an unrelated repository and merging, that's it. It's a lot simpler than splitting a repo up unless you accept that all of the old history can remain, then you just make a clone and delete what should no longer be a part of the repository.

But monorepo leads to tight coupling, and that is just as much a pain to work on as versioning, or two teams are simultaneously working on the same shared code, and you have not only merge conflicts, but conflicting functionality.

Re: Monorepos: Please don’t

#148

Post by rossjudson » Thu, Jan 03, 2019, 10:00 AM UTC

Hilariously misguided.

Pretty funny to read that the things I do every day are impossible.

Monorepo and tight coupling are orthogonal issues. Limits on coupling come from the build system, not from the source repository.

Yes, you should assume there is a sophisticated "VFS". What is this "checkout" you speak of? I have no time for that. I am too busy grepping the entire code base, which is apparently not possible.

If the "the realities of build/deploy management at scale are largely identical whether using a monorepo or polyrepo", then why on earth would google invest enormous effort constructing an entire ecosystem around a monorepo? Choices: 1) Google is dumb. 2) Mono and poly are not identical.

Re: Monorepos: Please don’t

#149

Post by tome » Thu, Jan 03, 2019, 10:01 AM UTC

malkia wrote: post #77

laurencei wrote: post #64

Can anyone here explain to me how a monorepo like Google or Facebook handles security? If I pull the repo - I have the entire contents of Google or Facebook? Is that right? Surely that lacks the normal security measures around what must be highly sensitive information, so there must be more to it than I know of?

(Worked at google for 2-3 years, under google3 depot) - AFAIK, only few hundreth files are not visible to employees, and certain folks (contractors) maybe limited there too. You can actually compile, and run in dev/staging certain things, inspect code, click on function, and see callsites, even "debug" from the browser (debugging, is pretty much, if your binary have stepped through a bookmark, then it'll tell you, an…

FTI: Apparently "google3" is the Google monorepo

https://news.ycombinator.com/item?id=17123620

Re: Monorepos: Please don’t

#150

Post by rkangel » Thu, Jan 03, 2019, 10:02 AM UTC

icebraining wrote: post #122

chvid wrote: post #92

Does a lot of the pain from a monorepo come from trying to use a tool - Git - that is explicitly designed to support distributed repositories? Wouldn't things be easier if you used eg. Subversion instead? That is a tool that was designed around a client/server paradigm and had a single repository as its main use case.

Git was designed for a monorepo (the kernel). When people talk about monorepo, they mean a single history line.

The kernel is not a monorepo. The kernel is a large(ish) repo.

A monorepo would be if you put the kernel AND userspace in the same repo (e.g. all the code for a Yocto distro). To me, when people talk about a monorepo they are talking about putting separate pieces of the architecture in a single repo.

It's a great example actually. If it was all in a monorepo and you could release it together then you wouldn't have to worry about the breaking userspace, you could make the changes to both sides at once. In practice because that's not how releasing works in that environment, you can't do that.