News for hackers. Stuff that matters.

A comment on Monorepos: Please don’t. Parent comment

Re:Monorepos: Please don’t by WorldMaker on Wednesday January 02, 2019 @05:03PM (#18810718)
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 "their" file and they got an automated notice from a hidden rules engine in your CI process you didn't even realize existed.

In the polyrepo case those boundaries have to be made explicit (otherwise no one gets anything done) and those owners should be easily visible. You may not like the friction they sometimes bring to the table, but at least it won't be a surprise.

[ Parent | on HN ]
Re:Monorepos: Please don’t by rgoulter on Wednesday January 02, 2019 @08:25PM (#18812034)
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.

[ Parent | on HN ]
Re:Monorepos: Please don’t by freedomben on Wednesday January 02, 2019 @09:23PM (#18812302)
> 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 :-)

[ Parent | on HN ]
Re:Monorepos: Please don’t by matwood on Thursday January 03, 2019 @07:26AM (#18814580)
I've also seen arbitrary separations of repos because 2 people didn't get along and couldn't work together.
[ Parent | on HN ]
Re:Monorepos: Please don’t by Mxtetris on Wednesday January 02, 2019 @11:17PM (#18812782)
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...

[ Parent | on HN ]
Re:Monorepos: Please don’t by lrem on Thursday January 03, 2019 @05:19AM (#18814109)
In Google, this is pretty explicit with a plaintext OWNERS file in the directory. Internal IDEs not only have an understanding of that, but can automatically suggest a minimal set of reviewers in a possibly close time zone and not out of office.
[ Parent | on HN ]
Re:Monorepos: Please don’t by xyzzyz on Thursday January 03, 2019 @01:26AM (#18813277)
Piper, Google’s implementation of monorepo, has that, and it is very important and widely used.
[ Parent | on HN ]
Re:Monorepos: Please don’t by maktouch on Thursday January 03, 2019 @12:41AM (#18813108)
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.

[ Parent | on HN ]
Re:Monorepos: Please don’t by briantakita on Thursday January 03, 2019 @08:41AM (#18814983)
For my clients, I use an open source monorepo submodule inside the client's proprietary monorepo. I can maintain the organizations' software while sharing common code.

So (mono)repos are composable.

[ Parent | on HN ]
Re:Monorepos: Please don’t by gusmd on Thursday January 03, 2019 @01:54AM (#18813389)
If I remember correctly, Gitlab has introduced some sort of ownership control where you can say who owns what directories for things like approving merge requests that affect those directories.
[ Parent | on HN ]
Re:Monorepos: Please don’t by dsumenkovic on Thursday January 03, 2019 @08:11AM (#18814773)
Hey, did you mean of assigning approvers based on code owners [1]? You can find more info about Code Owners and syntax at the documentation [2].

[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/1012 [2] https://docs.gitlab.com/ee/user/project/code_owners.html

[ Parent | on HN ]
Re:Monorepos: Please don’t by pulisse on Thursday January 03, 2019 @03:04AM (#18813590)
Github has this feature[1], which we use extensively in our monorepo.

[1] https://help.github.com/articles/about-codeowners/

[ Parent | on HN ]
Re:Monorepos: Please don’t by joatmon-snoo on Thursday January 03, 2019 @03:27AM (#18813659)
google3 uses the same model that Chromium does, see an example here: https://github.com/chromium/chromium/blob/master/chromeos/OW...
[ Parent | on HN ]
Re:Monorepos: Please don’t by monksy on Thursday January 03, 2019 @12:22AM (#18813011)
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.

[ Parent | on HN ]
Re:Monorepos: Please don’t by icebraining on Thursday January 03, 2019 @03:33AM (#18813675)
Git submodules are not in the same repo, they are a link from one repo to another, and you need to push to both if you make a change to the submodule. Maybe you're thinking of subtrees? I've never used those.
[ Parent | on HN ]