Explore the journey of Facebook's transition from Git to Mercurial, uncovering the technical and social dynamics that influenced one of the tech industry's pivotal decisions in source control management. This post delves into the reasons behind Facebook's shift, the challenges of scaling Git, and the pivotal role of community and collaboration in adopting Mercurial

Monorepos, performance problems, and a lot of asking

  • jet@hackertalks.comEnglish
    25·
    4 months ago

    Really good read.

    One thing they didn’t cover was why the monorepo is so appealing to facebook

    • OhNoMoreLemmy@lemmy.ml
      11·
      4 months ago

      If I had to guess I’d say it’s because fundamentally Facebook development is about deploying servers.

      As you move through the main branch, at any commit, you should have something that you can deploy. The moment you split the repo you lose this, and need to worry about keeping multiple repos aligned.

    • conciselyverbose@sh.itjust.works
      11·
      4 months ago

      Our code base has grown organically and its internal dependencies are very complex. 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. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn’t sit well with us.

      This is from the blogpost it links near the beginning. Also worth a read if you’re interested.

    • a lil bee 🐝@lemmy.world
      7·
      4 months ago

      I personally love a monorepo. It has to be managed effectively by the team, but the benefits are great. Most of it boils down to making more effective incentives for maintenance and care for downstream effects because “we all live here”. There are tradeoffs and it’s not for every situation or team though, for certain.

  • jqubed@lemmy.world
    141·
    4 months ago

    I’m not a programmer and don’t know how to use git, but at least have a basic understanding of what its use is. I think the Closing Thoughts has a pertinent lesson that’s much broader:

    I’m reminded of the classic wisdom that so many of history’s key technical decisions are human-driven, not technology-driven.

    Facebook didn’t adopt Mercurial because it was more performant than Git. They adopted it because the maintainers and codebase felt more open to collaboration. Facebook engineers met face-to-face with Mercurial maintainers and liked the idea of partnering. When it came to persuading the whole engineering org, the decision got buy-in due to thoughtful communication - not because one technology was strictly better than another.

    • conciselyverbose@sh.itjust.works
      2·
      4 months ago

      They made a point of mentioning the clarity and extensibility of the Python codebase as well (not sure if it was the article of the original blog) as making it easier to modify. They could have forked the code if they thought git was clearly better.

    • Aatube@kbin.melroy.orgOP
      2·
      4 months ago

      I do not see what you mean by the second paragraph.

      Complaining about ask as a noun, an innovation that only picked up recently, sounds like “old man yells at cloud”. I do not get your association with some 80s salesman and have never seen such usage in any contemporary films. Also, how the heck is a blog post “someone writing seriously”?