4 ms·

Maybe its just that the author's cutoff is at the wrong team size, but the monorepo I work on (with ~150 devs) has almost none of the problems presented. Unrea

Maybe its just that the author's cutoff is at the wrong team size, but the monorepo I work on (with ~150 devs) has almost none of the problems presented. Unreasonable for a single dev to have the entire repo? I'm looking at a repo with ~10 million LoC and ~1.4 million commits. I have 74 different branches checked out right now. Hard drives are cheap. Code refactors are impossible? I reviewed two of those this morning. They're essentially a non-event. I'm not sure what to make of the merge issue - does code review have to start over after a merge? That seems like a deep issue in your code review process. The service-oriented point seems like a non-sequitur, unless you're telling me I'm supposed to have a service for, say, my queue implementation or time library. The VCS scalability issue is the only real downside I see here. And it is real, but it also seems worth it. It helps that the big players are paving the way here - Facebook's contributions to the scalability of mercurial has definitely made a difference for us.

kiallmacinnes 8y ago
In theory, yes - if the underlying repo changes, code review should start over. In practice though, it's a terrible idea ;) Part of code review is to ensure the code "fits" with all other merged code - so a re-review is "needed" when other changes merge. E.g. if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account. In practice, this doesn't happen - it's way too much effort for far too little value.
- jen20 8y ago
  > if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account. To be fair, if you get away with merging that refactor, the review that needed more attention was of that refactor ;-)
- thedufer 8y ago
  I think the trick is to only re-review the areas that had merge conflicts, and to do the re-review aware of both the changes you already reviewed and the changes that caused the conflict. Merge conflicts, even in big code refactors, are fairly rare, so this ends up not being much additional work in practice.

kiallmacinnes 8y ago

In theory, yes - if the underlying repo changes, code review should start over. In practice though, it's a terrible idea ;) Part of code review is to ensure the code "fits" with all other merged code - so a re-review is "needed" when other changes merge. E.g. if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account. In practice, this doesn't happen - it's way too much effort for far too little value.

jen20 8y ago
> if I merge a refactor that changes everything from Pascal case to 100% SHOUTING, reviews now need to take this into account. To be fair, if you get away with merging that refactor, the review that needed more attention was of that refactor ;-)
thedufer 8y ago
I think the trick is to only re-review the areas that had merge conflicts, and to do the re-review aware of both the changes you already reviewed and the changes that caused the conflict. Merge conflicts, even in big code refactors, are fairly rare, so this ends up not being much additional work in practice.