Sapling 强调易用性，同时扩展到世界上最大的存储库。
Facebook揭幕 通过博客发布源代码管理系统 树苗 用于公司内部项目的开发。 系统 旨在提供一个版本控制接口 熟悉的，可以扩展到跨越数千万个文件、提交和分支的非常大的存储库。
该系统的主要思想是通过与提供存储库存储的服务器的特殊部分进行交互， 所有操作都根据文件数量进行缩放 实际上在开发人员正在处理的代码中使用，并且不依赖于整个存储库的总大小。
例如，开发人员可能只使用一个非常大的存储库中的一小部分代码，并且只有这一小部分而不是整个存储库会被转移到他们的系统中。 工作目录是动态填充的，因为存储库文件被访问，一方面，它允许您显着加快您的代码部分的工作，但另一方面，当您访问它时会减慢它的速度第一次访问新文件并需要持续的网络访问（单独提供和离线提交准备模式）。
除了自适应数据加载， Sapling 还实施优化，旨在减少具有更改历史记录的信息负载。 （例如，Linux 内核存储库中 3/4 的数据是更改历史记录）。
为了有效地使用更改历史记录，与其关联的数据存储在分段视图中，这允许您从服务器下载提交图的单独部分。 客户端可以向服务器询问有关多个确认关系的信息，并仅下载图形的必要部分。
该项目在过去 10 年中一直在开发 并且是为了解决在使用主分支访问非常大的单体存储库时出现的问题而创建的，其中实践了使用“rebase”操作而不是“merge”的做法。
当时，没有使用此类存储库的开放解决方案，Facebook 工程师决定创建一个新的版本控制系统来满足公司的需求，而不是将项目拆分成小的存储库，这会导致更复杂的依赖管理（有一次，为了解决类似的问题，Microsoft 创建了 GVFS 层）。
最初，Facebook 使用 Mercurial 系统 Sapling 项目最初是作为 Mercurial 的补充开发的。 随着时间的推移，该系统成为一个独立的项目 具有自己的协议、存储格式和算法，还扩展了与 Git 存储库交互的能力。
为了工作， 建议使用命令行实用程序“sl”， 它实现了典型的概念、工作流和熟悉 Git 和 Mercurial 的开发人员所熟悉的界面。 Sapling 中的术语和命令与 Git 略有不同，更接近于 Mercurial。
在附加功能中 树苗，突出了 支持“智能注册” (smartlog)，它允许您直观地评估存储库的状态， 突出显示最重要的信息并过滤掉次要的细节。 例如，当您不带参数运行 sl 实用程序时，只会显示您自己的本地更改（外部更改已折叠）、外部分支的状态、更改的文件和提交的新版本。 此外，还提供了一个交互式 Web 界面，用于通过智能日志、更改树和提交进行快速导航。
Sapling 的另一个显着改进是 它使修复和分析错误以及恢复到先前状态的过程变得更加容易。 例如，建议使用命令“sl undo”、“sl redo”、“sl uncommit”和“sl unmend”来撤销许多操作，“sl hide”和“sl unhide”用于临时隐藏提交和交互式导航。状态 Sapling 还支持提交堆栈的概念，它允许您通过将复杂的功能分解为更小、更易于理解的增量更改集（从基本框架到最终功能）来逐步组织审查。。
分别， 服务器部分的开发是为了有效地远程处理存储库 和一个虚拟文件系统，与存储库的一部分的本地部分一起工作，就好像它是一个完整的存储库一样（开发人员可以看到整个存储库，但只有请求的数据被复制到本地系统，可以访问）。
Facebook 基础设施中使用的这些组件的代码尚未公开，但该公司已承诺在未来发布。 然而，Mononoke 服务器（在 Rust 中）和 VFS EdenFS（在 C++ 中）原型已经可以在 Sapling 存储库中找到。 这些组件是可选的，Sapling 客户端就足够了，它支持克隆 Git 存储库，与基于 Git LFS 的服务器交互，以及与 GitHub 等 git 主机一起工作。
为 Sapling 准备了几个插件，包括用于审查更改的 ReviewStack 接口（GPLv2 下的代码），它允许您处理 GitHub 上的拉取请求并使用更改堆栈视图。
如果您有兴趣了解更多，可以查阅详情 在下面的链接中。