4 ms·

> We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using

by Touche 13y ago

> We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Pray tell?

kyrra 13y ago
From the article: >Splitting it up would make large, atomic refactorings more difficult. If you split the code base up into multiple projects, you need some sort of meta project to link them all together if you need to deploy it as a single entity. Doing a meta project isn't exactly easy, so it tends to be better to do a single project if everything is all tightly coupled still. The project could be split up into smaller modules that are linked via shared common interfaces, but takes more time to maintain.
- Touche 13y ago
  What is a wrong with submodules or subtree for a meta project? Or better yet, package management.
dudus 13y ago
On the other hand the Mercurial modularity was key for the migration.
georgemcbay 13y ago
I know nothing of the code Facebook is hosting, but one fairly obvious general benefit of having things in a single repository is that you can use relative paths to link dependent projects, like if you have a directory structure such as: libs libs/mylib apps apps/myapp then myapp can reference library mylib via ../../libs/mylib If all of these things are in separate repositories, all bets are off about how their paths relate to each other on the local filesystem, resulting in more complicated build procedures.
- markcampbell 13y ago
  There's a solution to this. Git submodules.
  - bostik 13y ago
    Please tell me if there's a way to make git-grep (or git-log for that matter) work between submodules. While I may not personally like behemoth repositories, I do see why people would choose to endure them. They do have their advantages, even if they all eventually end up looking something like BSD ports. (FYI: I happen to like the extremely modular one-git-repo-per-component approach as used in Mer. Hell, I did an early implementation of the OBS+git -based autobuild system back in 2009!)
  - nilved 13y ago
    git submodules don't fix anything except maybe a good day.
  - garenp 13y ago
    Sometimes the cure is worse than the disease.
- breck 13y ago
  You can still have the benefits of relative links without a single repo if you create a dir at the root level. For example, you can have a /facebook/ dir on every machine with the source, and all your subprojects can assume they are working off that, ie: include /facebook/somemodule
yonran 13y ago
I worked at Google (in a team using Perforce) and now work at a different company that uses multiple interdependent projects using Maven. Using a single monolithic codebase along with a build tool that statically builds everything at trunk has its advantages: * You immediately get improvements from upstream projects without having to get them manually. * You can unambiguously answer the question, What code am I using? with a single number. With multiple repositories, you have to list all the versions of each project that you are using. * Easy API refactoring. You don’t have to worry about coordinating version number bumps across different repositories/dependency manifests when you make major changes to inter-project APIs. With a monolithic repository, you fix all callers of an API using a single code commit. No need to edit the version numbers in your pom files. * Low cost to split a project into multiple separate projects. With multiple repositories or version numbers, you are reluctant to create new projects because the APIs will forever be harder to refactor (since you will have to worry about version numbers). * No diamond dependency problem of 2 dependencies using a different version of a base project. Everyone is using the same version of base. With a monolithic repository+build system, upstream callers are responsible to never make a commit that breaks downstream callers. I feel like it’s similar to the question of optimal currency areas. If your organization is growing in lock-step, then you can all happily share a single gold-standard repository with little friction. But if you can’t trust your upstream projects, you introduce versioning between the projects and have to deal with the mental burden of wondering whether to upgrade to the newest upstream project and whether you’re actually running the latest code. Edit: added a couple more.
- Touche 13y ago
  > * You immediately get improvements from upstream projects without having to get them manually. You also immediately get regressions. Not trying to be dismissive, but we fundamentally have different software philosophies if you think this point (which is the essence of most of your points) is a good thing that should be encouraged.
  - eropple 13y ago
    Test better.

by Touche 13y ago

> We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Pray tell?

kyrra 13y ago

From the article: >Splitting it up would make large, atomic refactorings more difficult. If you split the code base up into multiple projects, you need some sort of meta project to link them all together if you need to deploy it as a single entity. Doing a meta project isn't exactly easy, so it tends to be better to do a single project if everything is all tightly coupled still. The project could be split up into smaller modules that are linked via shared common interfaces, but takes more time to maintain.

Touche 13y ago
What is a wrong with submodules or subtree for a meta project? Or better yet, package management.

dudus 13y ago

On the other hand the Mercurial modularity was key for the migration.

georgemcbay 13y ago

I know nothing of the code Facebook is hosting, but one fairly obvious general benefit of having things in a single repository is that you can use relative paths to link dependent projects, like if you have a directory structure such as: libs libs/mylib apps apps/myapp then myapp can reference library mylib via ../../libs/mylib If all of these things are in separate repositories, all bets are off about how their paths relate to each other on the local filesystem, resulting in more complicated build procedures.

markcampbell 13y ago
There's a solution to this. Git submodules.
- bostik 13y ago
  Please tell me if there's a way to make git-grep (or git-log for that matter) work between submodules. While I may not personally like behemoth repositories, I do see why people would choose to endure them. They do have their advantages, even if they all eventually end up looking something like BSD ports. (FYI: I happen to like the extremely modular one-git-repo-per-component approach as used in Mer. Hell, I did an early implementation of the OBS+git -based autobuild system back in 2009!)
- nilved 13y ago
  git submodules don't fix anything except maybe a good day.
- garenp 13y ago
  Sometimes the cure is worse than the disease.
breck 13y ago
You can still have the benefits of relative links without a single repo if you create a dir at the root level. For example, you can have a /facebook/ dir on every machine with the source, and all your subprojects can assume they are working off that, ie: include /facebook/somemodule

yonran 13y ago

I worked at Google (in a team using Perforce) and now work at a different company that uses multiple interdependent projects using Maven. Using a single monolithic codebase along with a build tool that statically builds everything at trunk has its advantages: * You immediately get improvements from upstream projects without having to get them manually. * You can unambiguously answer the question, What code am I using? with a single number. With multiple repositories, you have to list all the versions of each project that you are using. * Easy API refactoring. You don’t have to worry about coordinating version number bumps across different repositories/dependency manifests when you make major changes to inter-project APIs. With a monolithic repository, you fix all callers of an API using a single code commit. No need to edit the version numbers in your pom files. * Low cost to split a project into multiple separate projects. With multiple repositories or version numbers, you are reluctant to create new projects because the APIs will forever be harder to refactor (since you will have to worry about version numbers). * No diamond dependency problem of 2 dependencies using a different version of a base project. Everyone is using the same version of base. With a monolithic repository+build system, upstream callers are responsible to never make a commit that breaks downstream callers. I feel like it’s similar to the question of optimal currency areas. If your organization is growing in lock-step, then you can all happily share a single gold-standard repository with little friction. But if you can’t trust your upstream projects, you introduce versioning between the projects and have to deal with the mental burden of wondering whether to upgrade to the newest upstream project and whether you’re actually running the latest code. Edit: added a couple more.

Touche 13y ago
> * You immediately get improvements from upstream projects without having to get them manually. You also immediately get regressions. Not trying to be dismissive, but we fundamentally have different software philosophies if you think this point (which is the essence of most of your points) is a good thing that should be encouraged.
- eropple 13y ago
  Test better.