系统与基础设施code.facebook.com
Facebook 如何扩展 Mercurial
Scaling Mercurial at Facebook
2014 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Facebook 工程博客关于为超大规模单一代码库扩展 Mercurial 的文章，介绍 Facebook 为何选择并改造 Mercurial 来支撑其代码库规模，以及相关的工程挑战和方案。文章也是大公司 monorepo 与版本控制工具选型的经典案例。
为什么经久不衰：它记录了大厂在单一代码库下把版本控制推到极限的真实工程取舍，今天讨论 monorepo、Mercurial/Git 选型时仍值得参考。
HN 评论精选
质疑单一大仓库的论证，认为模块化有可靠性收益，并追问缺点如何缓解。
文中说他们本可以把代码库做得更模块化，但单一仓库有利于持续现代化和大规模原子重构，不应让版本控制的扩展限制决定代码结构。评论者不认同：模块化的重要理由恰恰是提高可靠性；他想知道在大量提交者的情况下，Facebook 如何缓解单一大仓库的明显缺点。
danielrhodes查看英文原文
"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." I remember reading about their Git troubles awhile ago, and I still don't buy this argument that it is better to have one large repository. One reason modularization is important is for the precise reason they are trying to get around it: removing the ability to make large scale changes easy and thus increasing reliability. However, my understanding is that their desire to have one large repo is reflective of their their "move fast and break things" philosophy, which means not being afraid of making large scale changes. So I would be interested in hearing how they mitigate the obvious downsides given how many people they have committing to their codebase. It seems like you would just end up having to create constraints in other ways, so which constraints end up being the lesser of two evils?
提供 Facebook 选型背景的原始邮件列表链接。
补充背景：这是 Facebook 最初联系 Git 开发者的邮件列表线程，可了解他们为何最终选择 Mercurial 而不是 Git。
agwa查看英文原文
For some context of why Facebook choose Hg over Git, here's the mailing list thread where Facebook initially reached out to the Git developers: http://thread.gmane.org/gmane.comp.version-control.git/189776
用 Google 的例子说明大公司曾因 Git 扩展性问题转向其他方案。
文中说工程师熟悉 Git 也倾向保留它，但仔细评估后认为 Git 内部难以支撑一个雄心勃勃的扩展项目。评论还引用 Google 的经历：操作系统发布时 Git 不再能扩展，于是他们招走了大部分 Git 核心开发者。
xkarga00查看英文原文
"Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." http://www.techradar.com/news/software/how-open-source-changed-google-and-how-google-changed-open-source-1206582 "And then Git itself wasn't working for us anymore because it wasn't scaling when we'd have an operating system release. So we ended up hiring most of the Git team - there's like only one or two core committers now for Git who don't work at Google,"
单一大代码库各有取舍，没有放之四海而皆准的答案。
对“一个代码库统治一切”通常有两种反应：一是质疑为何让代码长成巨大而互相依赖，认为 Git 成为瓶颈是用法不对；二是认为这是务实的跨公司共享代码方式，减少孤岛，让大重构一次完成，修版本控制比重构百万行代码更划算。两种反应都成立，最佳方案取决于项目和团队。
Smudge查看英文原文
I generally see two reactions to the "one codebase to rule them all" approach (used by Facebook, Google, et. al): 1. Holy god why would you let your code grow to such a massive, interdependent scale? Just release everything separately and versioned so that breaking changes don't affect everyone all at once. The idea of git being a bottleneck is absurd and you are using it wrong. 2. This is a very reasonable, practical approach to sharing code across a company. It reduces siloing and ensures that major refactors can happen in one pass without a ton of coordination. Better to fix the version control system than waste endless resources refactoring millions of lines of code. Both reaction is valid. Having worked in both styles of codebase, I recognize that there are trade-offs in either case. The optimal solution depends on the project and the team. Sometimes the path of least resistance--that is to say, the path to getting things shipped and, in turn, making money--is to let the codebase grow organically and worry about cleaning up any messy interdependencies later, once you have a better idea of what code you even need to keep around. In this scenario, it's important to recognize that developer efficiency is going to be an uphill battle in the long run, but if you are proactive about maintenance and tooling improvements then this approach can still be relatively painless. Other times, especially when you're working on a tried-and-tested product with a clear API and a dedicated team, it can be productive to split it out and let the team manage their own versioning and releases. This becomes especially useful if the product is open source. (For instance, I wonder how Facebook manages its open source releases relative to its shared Mercurial codebase.) In this scenario, developer efficiency is usually less of a problem, as proper use of versioning can ensure faster, more agile updates to each product. But the downside is that your company as a whole can end up in a kind of versioning hell, where every project depends on a different version of every other project, and keeping everything up to date can require a huge amount of coordination. So, in the end, pick your poison. My reaction, years ago, was more along the lines of #1, but I used to be much more of an idealist earlier in my career.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选