Skip to content

SYSTEM Cited by 1 source

Sapling (SCM)

Sapling is Meta's source control system, developed internally over 10 years (2012–2022) to run Meta's monorepo at the scale of "tens of millions of files, tens of millions of commits, and tens of millions of branches" — a scale "public source control systems were not, and still are not, capable of handling." The client was open-sourced on 2022-11-15 at sapling-scm.com; the virtual file system and Sapling-compatible server were flagged as future open-source goals without commitment.

Genealogy: Sapling began as an extension to the Mercurial open-source project and grew into its own system "with new storage formats, wire protocols, algorithms, and behaviors." Sapling is not a Git fork — though the open-source client supports cloning and interacting with Git repositories and can be used as a Git-host client against GitHub et al.

The two orthogonal design axes

Sapling's thesis, and the rhetorical spine of the 2022-11-15 announcement post, is that usability and scale are independent design dimensions in source control — most existing tools (Git especially) made trade-offs between them. Sapling invests in both simultaneously.

Usability axis (sl CLI)

Every command does one thing. Sensible defaults:

  • Local branch names are optional. Commits on their own are sufficient to track your work.
  • No staging area. The pre-commit index is an optional concept, not a mandatory one.
  • The default view is useful. Running sl with no arguments invokes smartlog — a concise picture of local commits, relevant remote branches, file status, and new commit versions; irrelevant mainline history is hidden behind a dashed line.
  • Undo is a subsystem. sl undo, sl redo, sl uncommit, sl unamend, sl hide, sl unhide, and an interactive sl undo -i (Mac/Linux) scroller make repository recovery a first-class activity — per the post, "never again should you have to delete your repository and clone again to get things working." See patterns/vcs-undo-tooling.
  • Commit stacks are first-class. sl goto, sl amend, sl restack, sl next / sl prev / sl goto top/bottom, sl fold, sl split, sl absorb, sl amend --to COMMIT make the stack-of-small-reviewable-commits workflow a comfortable default. Sapling tracks mutation history (inspired by Mercurial Evolve) so the stack can be algorithmically rebuilt after any amount of editing. See patterns/first-class-commit-stack-workflow.
  • Web UI. sl web launches an interactive smartlog in the browser; supports commit/amend/checkout/etc.

Scale axis (Sapling server-backed repos)

Several scaling features require the Sapling-compatible server and do not apply when Sapling is used as a client against a Git host:

  • Lazy history download. Clone downloads almost no history; commits/trees/files are fetched on demand. Offline mode is preserved via cache + indexes; common flows like commit stay available offline.
  • Segmented Changelog. The high-level shape of the commit graph is downloaded in "just a few megabytes"; ancestry queries run in O(number-of-merges) from segments alone. log/blame/sl log FILE use bisection of the segment graph for O(log n) — "even in Git repositories." sl smartlog is "less than a second, regardless of how big the repository is."
  • Virtual file system (not yet open-sourced). Checkouts and clones are fast independent of working-copy size; files fetched on first access and cached. sl status is accelerated via Watchman even without the VFS.
  • Sparse checkouts + [[concepts/ sparse-profile|sparse profiles]]. Per-product sparse configurations are checked into the repo and owned by the product team — thousands of engineers pick up sparse-state changes automatically without per-engineer config. See patterns/organization-owned-sparse-profile.
  • Commit Cloud (preview / not yet open-sourced). All commits in the org auto-uploaded; sharing via commit hash + sl goto HASH.
  • Git LFS supported for large binary files.

Open-source scope at release

Explicitly disclosed in the post: "Many of our scale features require using a Sapling-specific server and are therefore unavailable in our initial client release."

Component Open-source at 2022-11-15?
Sapling client (sl) Yes
Git-repo compatibility Yes
Smartlog + smartlog web UI Yes
Commit-stack commands + mutation history Yes
Undo subsystem Yes
Segmented Changelog on Sapling-server repos No (server required)
Virtual file system No ("we hope to open-source")
Sapling-compatible server (Rust) No ("we hope to open-source")
Commit Cloud No (server-dependent)
Per-file history graphs No (server-dependent)

Seen in

Last updated · 319 distilled / 1,201 read