Interesting that both google and FB have single-repo source control. I wonder if it really reinforces the idea that code belongs to the team. I’ve definitely had some issues in the past that may...
Interesting that both google and FB have single-repo source control. I wonder if it really reinforces the idea that code belongs to the team.
I’ve definitely had some issues in the past that may have been avoided with a single-repo structure, but it seems like it would be chaotic.
Google's system is pretty cool, because as far as you are concerned on the daily the majority of the tree doesn't exist. It is there, however, and if you want to do something that touches many...
Google's system is pretty cool, because as far as you are concerned on the daily the majority of the tree doesn't exist. It is there, however, and if you want to do something that touches many parts in a single transaction you can.
I prefer people and projects to act independently, to build simpler systems with strong boundaries. When you have loads of people and loads of code you get tempted to build more complicated things because you can. That doesn't make them best. Look at istio. It has 40 odd employees working on it. It is a huge solution. Does the solution need to be that large? If they didn't have so many resources to throw at it what would change?
At work, each team has a GitHub org (on the company GH Enterprise) that they put all of their code under. A few teams have merged several projects into a monorepo with Lerna, but it's definitely...
At work, each team has a GitHub org (on the company GH Enterprise) that they put all of their code under. A few teams have merged several projects into a monorepo with Lerna, but it's definitely an uncommon practice. The usage of one org per team is apparently being revisited by management; they want to standardize the orgs so that people can more easily find code.
More so finding entire projects. Someone can hear about a project through word of mouth, but the "conversational" name of a tool rarely seems to be the name of the repo on GH, so finding the repo...
More so finding entire projects. Someone can hear about a project through word of mouth, but the "conversational" name of a tool rarely seems to be the name of the repo on GH, so finding the repo based solely off of the name can be hard.
I personally work with both monorepos and split repos. It's nice (especially in a company setting) because: You can trivially link to pretty much anything, and pretty much anything can trivially...
I personally work with both monorepos and split repos.
It's nice (especially in a company setting) because:
You can trivially link to pretty much anything, and pretty much anything can trivially link to you
A single version of dependencies is used across everything, if there's an vuln, you only need to patch it once
There's no overhead to starting to work on another part of the monorepo, just open the files
Org-wide refactors is made much easier
Tooling such as code search, CI metrics, etc are much easier to implement across the org
It's annoying because:
All your existing tooling will break due to the size and you'll have to rewrite it
People can break your code without you changing anything (unless you have good tests)
It's huge and everything will (in general) be much slower
Splitting things off later will make you hate life
On dependencies - how do you solve the problem of having conflicting "version needs" for external dependencies? For instance, if project A needs to upgrade the dependency for new functionality,...
On dependencies - how do you solve the problem of having conflicting "version needs" for external dependencies? For instance, if project A needs to upgrade the dependency for new functionality, but project B relies on deprecated functionality from the old version of the dependency? Is the project A team responsible for writing the new code project B needs to function?
What if the project B team is of the opinion that the newer version of the dependency isn't as good as the old version, and thus doesn't want to upgrade?
Interesting that both google and FB have single-repo source control. I wonder if it really reinforces the idea that code belongs to the team.
I’ve definitely had some issues in the past that may have been avoided with a single-repo structure, but it seems like it would be chaotic.
Anyone had experience with this?
Google's system is pretty cool, because as far as you are concerned on the daily the majority of the tree doesn't exist. It is there, however, and if you want to do something that touches many parts in a single transaction you can.
I prefer people and projects to act independently, to build simpler systems with strong boundaries. When you have loads of people and loads of code you get tempted to build more complicated things because you can. That doesn't make them best. Look at istio. It has 40 odd employees working on it. It is a huge solution. Does the solution need to be that large? If they didn't have so many resources to throw at it what would change?
At work, each team has a GitHub org (on the company GH Enterprise) that they put all of their code under. A few teams have merged several projects into a monorepo with Lerna, but it's definitely an uncommon practice. The usage of one org per team is apparently being revisited by management; they want to standardize the orgs so that people can more easily find code.
By "find code" do you mean doing global text searches? What are the use cases around finding code?
More so finding entire projects. Someone can hear about a project through word of mouth, but the "conversational" name of a tool rarely seems to be the name of the repo on GH, so finding the repo based solely off of the name can be hard.
I personally work with both monorepos and split repos.
It's nice (especially in a company setting) because:
It's annoying because:
On dependencies - how do you solve the problem of having conflicting "version needs" for external dependencies? For instance, if project A needs to upgrade the dependency for new functionality, but project B relies on deprecated functionality from the old version of the dependency? Is the project A team responsible for writing the new code project B needs to function?
What if the project B team is of the opinion that the newer version of the dependency isn't as good as the old version, and thus doesn't want to upgrade?
Are there any good open-source tools for operating a monorepo?