It's funny you say this, because my most viewed article from organic searches is about converting your polyrepo setup to a monorepo https://www.jvt.me/posts/2018/06/01/git-subtree-monorepo/
Monorepos: Please don’t
161–170 of 402 posts
Re: Monorepos: Please don’t
#162Earlier quoted context omitted.
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.
Well... Why does that make sense? I have a repository containing both the GUI and the server, and sometimes I have to make changes to both. Locating those related changes together in the same commit and/or PR makes a lot of sense to me: the changes depend on each other, and thus should be reviewed together. What's the advantage of splitting them up?
Re: Monorepos: Please don’t
#163I wish this had touched on polyrepos' ability to pin known-good versions of dependencies; that tends to be the Achilles' heel of monorepos.
Hmm. Monorepos strongly favor "always-good". Core library breakage gets detected and rolled back really fast. It's been months since I've been affected by one.
Known-good is in the eye of the beholder, and is just another dimension that generates breakage.
Re: Monorepos: Please don’t
#164Hilariously 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…
> 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.
I think, once you've chosen a path of mono or poly, you have quite a challenge ahead of you to migrate to the other.
At that point, the tradeoffs arent based purely on the technical benefits - and "invest in monorepo tooling" may become a perfectly valid decision, as it's cheaper than "migrate to a polyrepo setup'.
I'm not arguing either way for or against monorepo, just pointing out that "must be a good idea because Google does it" is invalid - technical merit is just one of the thousands of concerns to be balanced.
Re: Monorepos: Please don’t
#165Can 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?
(there's an acm paper about Google's repo that dives deeper into this). First thing, you can't just "pull the whole repo" at Google or fb scale. It doesn't fit on a single hard drive. This means the enitre repo is normally accessed via networked means. As a result, builds can also be done over the network transparently. So building and testing is done as a different user. That user can have different privileges than…
Link to the paper "Why Google Stores Billions of Lines of Code in a Single Repository" https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
Also, "Software Engineering at Google" https://arxiv.org/pdf/1702.01715.pdf
Re: Monorepos: Please don’t
#166Earlier quoted context omitted.
> Monorepos allow you to do very bad hacks (I need this other component over there; let me just put in a Symlink. Done.). Why would you put in a symlink? You could just provide a path to the actual component and import it into your project. > the worst thing you can get that you'll have to assemble multiple distinct, well-encapsulated (in terms of project structure) things into one When you have multiple repos, you a…
> Why would you put in a symlink? You could just provide a path to the actual component and import it into your project. Where do I need to put the path again? Ah what the heck, I'll just add a symlink inside a folder that's already somewhere in the build definitions.
No VCS will ever protect you from crappy code though.
Re: Monorepos: Please don’t
#167Earlier quoted context omitted.
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?
Yeah, it's two separate monorepos. There is actually some shared code between multiple monorepos. Code like IDL's and some C mapping code are shared, but they are referenced as vendor libraries so each monorepo updates those dependencies when they need to. If you think about Android vs iOS vs a web based dispatch system vs an autonomy system; They are all totally different. All of the code, dependencies, vendor code (external dependencies), and tools in each monorepo are "platform" specific and live in each respective monorepo.
Each monorepo is solving one cognitive problem domain with all of the libraries and dependencies that go with it usually for a target platform. Every iOS app that Uber builds lives in one repository — you clone that down and you can build Rider, Driver, Eats, Freight, and Jump. They all use the same networking stack, same UI stack, same map stack, same VIPER architecture, etc. This makes it easy for someone who is an iOS dev to work in any app or spin up a new app with almost no effort.
But, you're right... it's not a monorepo in the sense that all of the code in the company is in one place. Maybe I like micro-monorepos.
Re: Monorepos: Please don’t
#168One 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)
Thanks for sharing
Re: Monorepos: Please don’t
#169Earlier quoted context omitted.
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.
>It makes absolutely sense to have a repository for the gui and one for the server.
Not really. You can have a single repo with top level directories tigershark-gui and tigershark-server.
Re: Monorepos: Please don’t
#170Earlier quoted context omitted.
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.
It'll be really typical for a gui/server to want to share some is_valid_payload() function. The client to validate it before sending, and for the server to do its own validation.
If it's a monorepo your PR might be a 2 line patch to that function, then adding the GUI and server code.
If you split it you'll first need to have a PR on the "validation-lib" repo, then once that gets in a PR on the "server" repo, bumping the "validation-lib" version dependency, and finally a PR on the "gui" repo bumping the dependency for both "validation-lib" and "server" (for testing etc.). That's before you need do deal with the circular dependency that "server" also wants "gui" for its own "I changed my server code, does the GUI work?" testing.
Better just to have them in a monorepo if they're logically the same code and want to share various components.