Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monorepos: Please don’t

medium.com

Post reply on HN
Print view View original

131–140 of 402 posts

Re: Monorepos: Please don’t

#131

Post by [deleted] »

icebraining wrote: post #126
forrestthewoods wrote: post #79

Earlier quoted context omitted.

I strongly agree. I hate this style of blog post. Telling people what they should or should not do is generally absurd. Every situation is unique and you can't possibly know another project's requirements or acceptable trade-offs. A better approach, in my opinion, is "Here's what we did and why". The author clearly has experience in the area. Great! Tell me about your problems. Tell me about your attempted solutions…

Isn't your own post telling people what they should and should not do (specifically on how to give advice)?

[deleted]

Re: Monorepos: Please don’t

#132

Post by rkangel »

0xFACEFEED wrote: post #99
wcdolphin wrote: post #97

Earlier quoted context omitted.

No. The worst case is that the engineering team spent more time working on “well encapsulated projects” than on the most important project for their business and are all now out of jobs. Most companies don’t fail because of tech debt. And certainly not because of version control tech debt.

Exactly. Whenever I see an engineer take a hardline position (eg: "no monorepos you zealots!") I always ask myself: is this person just annoyed? Most of the time they're just annoyed. One side effect of every successful business are annoyed worker ants that are sick of dealing with growth problems. I've been there. I know how annoying it can be. Personally I've found comfort in embracing the chaos and learning to man…

I agree. Any article (like the linked one) that states one side of a case as an absolute without giving any exceptions or caveats is going to be greeted by me with scepticism. Particularly as he keeps mentioning 3 large engineering organisations that disagree with him.

Re: Monorepos: Please don’t

#133

Post by forrestthewoods »

icebraining wrote: post #126
forrestthewoods wrote: post #79

Earlier quoted context omitted.

I strongly agree. I hate this style of blog post. Telling people what they should or should not do is generally absurd. Every situation is unique and you can't possibly know another project's requirements or acceptable trade-offs. A better approach, in my opinion, is "Here's what we did and why". The author clearly has experience in the area. Great! Tell me about your problems. Tell me about your attempted solutions…

Isn't your own post telling people what they should and should not do (specifically on how to give advice)?

The irony wasn't lost on me. It's a fine line. Let me try a slightly different approach.

When I blog I've had much better luck telling people "here's what I did and why". I don't know your circumstances and can't tell you how to solve your problems. You may need to choose different trade-offs than I did. With that said, here is my problem, how I solved it, and what I learned along the way. Hopefully you can learn from my experiences and make a more informed decision for how to handle problems you may encounter.

Re: Monorepos: Please don’t

#134

Post by sbr464 »

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.

Re: Monorepos: Please don’t

#135

Post by rkangel »

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.

Anecdotally - I worked on a ~1 million lines of C project in SVN for a number of years (it was a Bluetooth stack). SVN handled it (mostly) fine.

Re: Monorepos: Please don’t

#136

Post by username90 »

wtracy wrote: post #60

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

Why would those things be issues? At Google there multiple new commits per second and it works mostly fine, you just need a VCS which is made for a monorepo.

Re: Monorepos: Please don’t

#137

Post by robaato »

malkia wrote: post #69

I do really like mono-repos, but google's other significant new project: fuchsia - is set-up as multi-git repo (and I believe chromium too, maybe android (haven't checked)). For fuchsia, they use a tool called "jiri"[1] to update the repos, previously (and maybe still in use) is the "gclient" sync tool [2] way from depot_tools[3] [1] - https://fuchsia.googlesource.com/jiri/ [2] - https://chromium.googlesource.com/chr…

Having worked with some organisations building on Android (>1,000 repos), life is not easy when you are trying to build on top of it and regularly take updates etc.

I asked one company how many changes required changes to more than one repo and was told "a small percentage". We then did some basic analysis of issue IDs across commits and discovered that it was in reality nearer 30% of changes. Keeping those together was just plain very hard.

Start to scale this by teams of hundreds or thousands of devs and you get a lot of pain.

Managing branches is also hard - easy to create (with repo tool) - but hard to track changes.

Re: Monorepos: Please don’t

#138

Post by tome »

adrianN wrote: post #90
0xFACEFEED wrote: post #52

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

You can't split monorepos after the fact, at least not without immense costs. You can always just put all your small repos into a big one.

It's funny you say that, because the currently top-voted comment says exactly the opposite: https://news.ycombinator.com/item?id=18811368

Re: Monorepos: Please don’t

#139

Post by rkangel »

sterlind wrote: post #7

Could you get the best of both worlds by having a monorepo of submodules? Code would live in separate repos, but references would be declared in the monorepo. Checkins and rollbacks to the monorepo would trigger CI.

This is the approach taken by a number of projects. The ones I am most familiar with are the OpenEmbedded/Yocto/Angstrom family that build Linux for embedded devices. They have a 'root' repo that references the layer repos (using metadata files rather than submodules), and there is a tool that does the pulling. It's optimised for pulling not committing though, I don't think the tooling helps much with bumping versions.

It can be misused though - the releases of the root repository reference the children by tags usually. Someone retagged a child repo and we suddenly had build failures.

Re: Monorepos: Please don’t

#140

Post by jonex »

woolvalley wrote: post #123
jonex wrote: post #21

Seems like the main point is that you'll still need to add additional tooling (search, local cloning, build, etc) to handle scaling, something you can do just as well with polyrepos. Conversely, for polyrepos, you can add tooling to fix issues with dependency management and multi-project changes/reviews. However, the author figures that monorepos engourage bad code culture and points out that Git is hard to build a m…

What is the tooling for multi-repo atomic synchronized commits? Monorepo's give you that for free, which is the reason why I think monorepo projects exist. SVN kind of gave you partial checkouts, which was helpful.

Yes I think so too. But of course, as the article points out, nothing is entirely free. At some point we will have to build tools to handle scaling, and then the trade offs between a mono and polyrepo becomes less obvious. I'd lean towards monorepos as a base either way, but given sufficiently well working tooling it might not matter much.
Post reply on HN