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 上的拉取請求並使用更改堆棧視圖。
如果您有興趣了解更多，可以查閱詳情 在下面的鏈接中。