2005年4月，Larry发现有Linux内核开发者违反了协议，正在对自己的宝贝软件BitKeeper做逆向工程，他怒不可遏，撤销了Linux的使用许可。
（详情参见：被Linux之父力挺的软件，开源后倒下了...）
Linux一下子面临着没有源码管理系统的窘境！
这件事情影响很大，第一，Linus Torvalds不得不停下内核的开发和管理工作，开始开发Git。
第二，它促使Olivia Mackall发布了几周前开发的Mercurial v0.1 ，和Git一样，这也是一个可扩展的分布式版本控制系统。
两个分布式版本控制系统可以说是同时起步。
很明显，顶着Linux光环的Git（当然它自身非常优秀）受到了更多人的欢迎，很多公司选择了Git，其中就包括互联网巨头Facebook。
随着业务的飞速发展，Facebook的代码库也开始以惊人的速度增长。
单单是2013年，Facebook的Git代码仓库就提交了4.4万个文件，1700万行代码，甚至比Linux内核的规模更庞大，更复杂。
更要命的是，Facebook和另外一个巨头Google一样，把公司的所有项目代码都“塞”到了一个代码库中！
为什么要单一代码库的策略呢？这么做有很多好处：
(1) 统一的版本化管理，不需要fork 共享库，没有跨代码库merge复制代码的痛苦
(2) 广泛的代码共享和复用
(3) 简化的依赖管理
(4) 跨团队的合作很方便
可是，随着单一代码库的飞速增长，Git操作变得越来越慢。
Facebook的工程师对未来几年的代码库规模做了估计，创建了一个虚拟仓库做一个模拟，结果让人震惊，基本的Git命令都需要45分钟才能完成！
必须得寻找解决方案了！
Facebook组建了一个团队，专门来解决这个问题。
他们先是联系了Git维护者，但是要想解决Facebook的问题，Git内部必须得做一些深度的代码修改不可。
所以Git维护者的回复是：你们的代码库太大了，应该分拆代码库......
Git社区对于提升单一超大代码库的性能并不是十分积极，因为很少人这么用啊！
Git这条路走不通，Facebook又考虑了闭源的Perforce，这也是一个老牌的版本控制系统，成立于1995年。
Salesforce、Netflix、SAP、迪士尼、Intuit和纽约证券交易所都是它的客户，Google也曾经用过，Perforce在游戏领域是领导者，游戏厂商前20强有18家在用Perforce做版本控制。
在和Perforce的销售工程师接触的时候，Facebook发现Perforce在“读取和写入节点的本地一致性存在缺陷。” 不过Perforce并不认为这是一个大问题，也没有计划来解决它。
放弃了Perforce以后，一个有丰富Mercurial使用经验的工程师建议考虑一下Mercurial。
Mercurial用Python写成，采用了面向对象的各种模式，架构更简洁，更容易扩展。
比如对于Facebook这样大规模的存储库，一个主要的瓶颈就是找出哪些文件发生了变化。Git的办法是检查每个文件，随着文件数量的增加，就会变得越来越慢。
Facebook内部有个工具叫做watchman，可以检测文件的状态变化，Mercurial 良好设计使得和watchman的集成非常简单，最终集成了watchman的Mercurial在查看文件状态时，比Git快了5倍以上。
Mercurial还有几个很好的抽象，例如filelog，这个数据结构表示每个文件的每次修订，Facebook通过remotefilelog扩展了这个接口，使得超大存储库的pull和clone速度提升了10倍以上，从几分钟缩短到几秒钟。
Mercurial社区也非常开放，愿意和Facebook合作，为了解决Facebook遇到的问题，可以对Mercurial做出重大变革。
双方合作相当良好，Facebook从Git向Mercurial迁移的时候，在一年半的时间内贡献了500多个补丁，包括新的图算法，用C语言重写性能关键的部分等等。
Mercurial则认真地审阅这些补丁，主动帮助Facebook解决扩展性问题，在设计新功能的时候也会把Facebook的问题考虑在内。
这和当时的Git社区形成了鲜明的对比。
十年后，Git也做出了重大改进，可以很好地处理非常大的单一存储库，但
Facebook不会再迁移回来了。
说完了Facebook，再来说说Google。
Google的代码库更大，更加吓人。
截止到2015年，这个代码库一共有20亿行代码，占据了86T的空间。
数字没有直观感觉，看个图吧：Windows，Office等常见软件在中间，Google代码库是最下方的绿色方块。
除了Chrome和Android之外，大部分Google产品的代码都保存在一个代码库中。
Google最早用的版本控制系统是闭源的Perforce，可见在创业初期，像版本管理这样的工具，大家都是拿来就用的，不考虑什么开源不开源的。
为了支撑自己业务的发展，Google不断地想办法扩展Perforce，但是扩展也是到了尽头：CPU超负荷运转，时不时出现TCP连接失败。
Google也考虑了Git，但当时Git的主流观点是：应该使用更多更小的代码库。这和Google单一代码库的理念是完全相反。
就像2005年Linus被迫发明Git一样，Google也被迫发明了自己新的版本管理系统：Piper
新工具开发起来很容易，但是把数据从Perforce迁移到Piper非常难。
在过去的11年间，Perforce已经深深地融入了Google的生态系统，基于Perforce Google已经开发了300多种工具。
2010年，Oracle状告Google，指控它在Android中使用了未经授权的Java API，这给Google敲响了警钟，千万不用复制Perforce的API。
最后Google工程师不得不采用了“洁净室”的技术，由独立的，对Perforce API一无所知的工程师来进行设计。
向Piper的迁移花费了4年的时候，才大功告成。
Facebook和Google都是标准的互联网巨头，在他们代码库的发展过程中，一直坚持单一代码库的策略，都“抛弃”了Git。
Facebook选择现成开源软件Mercurial，疯狂魔改，使其满足自己的要求。
Google则选择发明一个新轮子Piper，花费巨大经历进行迁移。
他们所做的事情，不是一般公司能干的，对绝大多数公司来说，选择Git就足够了。
全文完，觉得不错的话点个赞或者在看吧！
转自：码农翻身
本文作者刘欣，著有畅销书《码农翻身》，《半小时漫画计算机》，前IBM架构师，领导过多个企业应用架构设计和开发工作；洞察技术本质，擅长用故事去讲解复杂技术。
