7 votes

Scaling Mercurial at Facebook (2014)

8 comments

  1. [7]
    GoingMerry
    Link
    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.

    Anyone had experience with this?

    4 votes
    1. bme
      Link Parent
      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?

      2 votes
    2. [3]
      Celeo
      Link Parent
      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.

      1 vote
      1. [2]
        GoingMerry
        Link Parent
        By "find code" do you mean doing global text searches? What are the use cases around finding code?

        By "find code" do you mean doing global text searches? What are the use cases around finding code?

        1. Celeo
          Link Parent
          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.

    3. [2]
      reentry
      Link Parent
      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
      1 vote
      1. GoingMerry
        Link Parent
        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?

  2. joelthelion
    Link
    Are there any good open-source tools for operating a monorepo?

    Are there any good open-source tools for operating a monorepo?

    1 vote