在2015年F8 conference video（从8:40开始）中，他们谈到了使用Mercurial和Facebook上的单个存储库的优势。
这在实践中如何运作？使用Mercurial，我可以签出一个子目录（在SVN中生活）吗？如果是这样，怎么样？我需要facebook-mercurial-extension吗
答案 0 :(得分：5)
从您的问题来看，目前尚不清楚您是在寻找工作流程（monorepo与多重回购辩论），还是在寻找巨大代码库的性能和扩展。
对于工作流程，我建议使用Google搜索monorepo。它有其优点和缺点，您需要了解您的情况和当前的工作流程来决定。对于性能和缩放，请继续阅读。
remotefilelog的想法不是检查一个子目录（正如你所提到的），我们的想法是检查所有内容。为了以有效的方式做到这一点，您需要Facebook积极开发的两个扩展：
hg clone和hg pull时间。hgwatchman，它现在是mercurial核心的一部分）。这大大减少了hg status等本地操作的时间。请注意，fsmonitor独立于remotefilelog。您可以开始尝试这一点，因为它不需要在服务器端进行任何设置。使用最近的mercurial（我强烈建议），您可以使用CommandServer + CHg减少Python解释器的额外启动时间。
一些补充说明：
fsmonitor。它工作得非常好，在巨大的回购中，hg status的时间从10秒减少到不到1秒（这1秒的大部分时间是Python启动时间，见上文CHg）。如果您的存储库非常庞大，您可能需要微调一些inotify内核参数（或MacOSX上的等效参数）。 fsmonitor文档包含您需要的所有信息。remotefilelog，虽然我读了我发现的一切，但我确信它有效。根据开发的完成方式（每个人都有互联网连接与否，组织是否有自己的主回购）可能有一个警告：它将分散的hg部分转换为集中式VCS，如{{1}通常可以离线完成的一些操作（例如：svn和过去的变更集的第一个hg log）现在需要连接到主存储库。hg update之前，我在一个巨大的回购中广泛使用了remotefilelog扩展名。它具有与largefiles相同的缺点，并且对于想要使用remotefilelog只是为了完成工作而没有花时间了解其工作原理的用户而言，存在一些令人困惑的极端情况。如果我要管理另一个巨大的回购，我会使用hg而不是remotefilelog，尽管他们的用例并不相同。largefiles（doc1，doc2）。问题是它会根据您在源树中的位置更改hg的行为。同样，如果开发人员不关心真正了解hg的工作方式，那将会太令人困惑。其他信息：
subrepositories。答案 1 :(得分：0)
我不确定这些答案是否仍适用于FB提出的所有努力 进入它
（2017年初）相关问题的答案仍然适用（因为它们偶尔会更新），但请注意，您必须阅读所有评论和答案。
remotefilelog本质上允许随需应变的浅层克隆（因此您无需一直获取所有内容的历史记录），但您仍然可以获取所有目录中的基本元数据并检出在期望的修订版中的回购。
使用Mercurial，我可以查看子目录（SVN中的li [k] e）吗？如果是这样，怎么样？
https://stackoverflow.com/a/40355673/7836056讨论了如何使用第三方扩展程序允许使用Mercurial缩小/稀疏检出（Facebook的sparse.py）或缩小克隆（Google的NarrowHG） ＃34;创建＆＃34;主存储库中的单个目录（虽然具有完全不同的权衡）。
（注意措辞很重要：＆＃34;稀疏结账＆＃34;在使用它来引用集中版本控制时，以不存在的方式引用分布式版本控制时意味着非常具体的操作）