7 ms·

But what are the alternatives to the monorepo in git? All the ways of splitting code up and deploying multiple git repos for one project seem terrible.

forrestthewoods 8y ago
> what are the alternatives to the monorepo in git? A monorepo in Perforce!
threeseed 8y ago
I don't understand why people are against this. You can have per repo branches/tags, the history is clean and relevant, it's easy to triage breakages, easy for different apps to have different versions of code etc. Plus for CI/CD it's trivial to just have one Jenkins jobs per repo as well and simple Git commit triggers. The entire programming world revolves around libraries and yet when it comes to our own code we are afraid of them ? Strange.
reificator 8y ago
> multiple git repos for one project If it's one project, it's not a monorepo. It's a repo.
- acomjean 8y ago
  We wanted to have a "common" subsystem that was common across projects. Being able to add and work on the common area and new projects at the same time was important. Pushing the common area back and being able to deploy to the older projects and test was important. This seems difficult in git. There are "submodules" and "subtrees" but none seemed particularly great and as far as I could tell each came with a bunch of caveats. I'll admit my Git skills aren't great, but I've used a variety of source control and tried to suss out the best way to deal with a small team. We ended up using "git subrepo" which is an add on thing I don't love, but it works. part of the motivation is "common" and "project 2" are to be open sourced, but "project 1" which also uses "common" isn't.
  - deleted 8y ago
    [deleted]
flukus 8y ago
> All the ways of splitting code up and deploying multiple git repos for one project seem terrible. Of course they are, git isn't the tool for this. You don't want multiple repos for a single project, you want one per project (this is not a monorepo). If there are things like code common to multiple projects then they are their own project with their own repo and release schedule, releases go into some sort of package manager (even if it's just the file system) and the projects depending on that common code update as they go.
- ebikelaw 8y ago
  See, this is where your argument broke down for me. Once you’ve decided there is some library of common code, and assuming you factor out that code into another repo, you’ve just lost your ability to easily make breaking changes to the common code, which is something trivially easy to do in a monorepo. Why would you want that? It seems to me that if you have multiple projects sharing a base of common code then a monorepo is clearly superior.
  - flukus 8y ago
    > you’ve just lost your ability to easily make breaking changes to the common code I haven't lost anything, I've gained the ability to make breaking changes because I don't have to update everything that breaks all at once. I don't have to do it at all because that's the job of the team responsible. With a monorepo what happens when their are 17 projects using the common code and I'm not familiar with 16 of them? Do I have to dive into the code of all 16 and fix them?
    - vkou 8y ago
      You can soft-deprecate the old code path, and communicate that warnings will turn into errors at some future date. You can send your pull request to the affected team leads, and request that they approve it, once they make changes on their end. I mean, the alternative is that you have 17 different projects, each using one of five different versions of the common code. Heaven forbid one of them makes an incorrect assumption about another. Getting 17 different teams to dance together around a breaking change is always going to be hard.
tiglionabbit 8y ago
Fun fact. I asked Facebook why they built their monorepo on Mercurial instead of Git. They said there were scaling issues in Git that made it unusable for large repos and the Git maintainers would not work with them to fix these issues. However, they were able to work with Mercurial to make it capable of holding their entire company in one repo.
- favorited 8y ago
  Someone from FB did a really cringe-inducing presentation a few years ago about how "X can't handle our scale" (I think the predicate was iOS, but they went into IDEs and SCM systems). They had to pull the video and slides because it was so bad.
  - tiglionabbit 8y ago
    XCode also had issues working with large repos. Perhaps they were talking about that?
    - Khoth 8y ago
      IIRC their iPhone app had about 20000 classes for some insane reason, and the system didn't handle that well.
      - gowld 8y ago
        https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920/ https://www.facebook.com/notes/facebook-engineering/under-th... Facebook patched Android Dalvik to increase the "max methods per app" limit. Don't know if there's a similar iOs story.
    - favorited 8y ago
      Responding late, so you might not see this. The thing that was so ridiculous to me was Facebook pretending that their app is somehow orders of magnitude more complicated than everyone else's. They're whole schtick was "we're Facebook and we have unique scaling needs that no one else does," which makes absolutely no sense from the perspective of one user's content being rendered on their phone. Plus the presenter was pretty smug, like all of this was good, when he wasn't convincing anyone that it was even necessary. Found the slides: https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pdf https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pd...

forrestthewoods 8y ago

> what are the alternatives to the monorepo in git? A monorepo in Perforce!

threeseed 8y ago

I don't understand why people are against this. You can have per repo branches/tags, the history is clean and relevant, it's easy to triage breakages, easy for different apps to have different versions of code etc. Plus for CI/CD it's trivial to just have one Jenkins jobs per repo as well and simple Git commit triggers. The entire programming world revolves around libraries and yet when it comes to our own code we are afraid of them ? Strange.

reificator 8y ago

> multiple git repos for one project If it's one project, it's not a monorepo. It's a repo.

acomjean 8y ago
We wanted to have a "common" subsystem that was common across projects. Being able to add and work on the common area and new projects at the same time was important. Pushing the common area back and being able to deploy to the older projects and test was important. This seems difficult in git. There are "submodules" and "subtrees" but none seemed particularly great and as far as I could tell each came with a bunch of caveats. I'll admit my Git skills aren't great, but I've used a variety of source control and tried to suss out the best way to deal with a small team. We ended up using "git subrepo" which is an add on thing I don't love, but it works. part of the motivation is "common" and "project 2" are to be open sourced, but "project 1" which also uses "common" isn't.
- deleted 8y ago
  [deleted]

flukus 8y ago

> All the ways of splitting code up and deploying multiple git repos for one project seem terrible. Of course they are, git isn't the tool for this. You don't want multiple repos for a single project, you want one per project (this is not a monorepo). If there are things like code common to multiple projects then they are their own project with their own repo and release schedule, releases go into some sort of package manager (even if it's just the file system) and the projects depending on that common code update as they go.

ebikelaw 8y ago
See, this is where your argument broke down for me. Once you’ve decided there is some library of common code, and assuming you factor out that code into another repo, you’ve just lost your ability to easily make breaking changes to the common code, which is something trivially easy to do in a monorepo. Why would you want that? It seems to me that if you have multiple projects sharing a base of common code then a monorepo is clearly superior.
- flukus 8y ago
  > you’ve just lost your ability to easily make breaking changes to the common code I haven't lost anything, I've gained the ability to make breaking changes because I don't have to update everything that breaks all at once. I don't have to do it at all because that's the job of the team responsible. With a monorepo what happens when their are 17 projects using the common code and I'm not familiar with 16 of them? Do I have to dive into the code of all 16 and fix them?
  - vkou 8y ago
    You can soft-deprecate the old code path, and communicate that warnings will turn into errors at some future date. You can send your pull request to the affected team leads, and request that they approve it, once they make changes on their end. I mean, the alternative is that you have 17 different projects, each using one of five different versions of the common code. Heaven forbid one of them makes an incorrect assumption about another. Getting 17 different teams to dance together around a breaking change is always going to be hard.

tiglionabbit 8y ago

Fun fact. I asked Facebook why they built their monorepo on Mercurial instead of Git. They said there were scaling issues in Git that made it unusable for large repos and the Git maintainers would not work with them to fix these issues. However, they were able to work with Mercurial to make it capable of holding their entire company in one repo.

favorited 8y ago
Someone from FB did a really cringe-inducing presentation a few years ago about how "X can't handle our scale" (I think the predicate was iOS, but they went into IDEs and SCM systems). They had to pull the video and slides because it was so bad.
- tiglionabbit 8y ago
  XCode also had issues working with large repos. Perhaps they were talking about that?
  - Khoth 8y ago
    IIRC their iPhone app had about 20000 classes for some insane reason, and the system didn't handle that well.
    - gowld 8y ago
      https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920/ https://www.facebook.com/notes/facebook-engineering/under-th... Facebook patched Android Dalvik to increase the "max methods per app" limit. Don't know if there's a similar iOs story.
  - favorited 8y ago
    Responding late, so you might not see this. The thing that was so ridiculous to me was Facebook pretending that their app is somehow orders of magnitude more complicated than everyone else's. They're whole schtick was "we're Facebook and we have unique scaling needs that no one else does," which makes absolutely no sense from the perspective of one user's content being rendered on their phone. Plus the presenter was pretty smug, like all of this was good, when he wasn't convincing anyone that it was even necessary. Found the slides: https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pdf https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pd...