CONCEPT Cited by 1 source
Sparse profile¶
A sparse profile is a named, checked-in description of which subset of the repository a particular product / team / role needs in their working copy. When a developer clones the repository, they enable the profile "for their particular product" and get the matching sparse checkout.
Canonical wiki instance: Sapling at Meta.
Operational model¶
Per the 2022-11-15 Sapling announcement post:
"Instead of each developer configuring and maintaining their own list of which files should be included, organizations can commit 'sparse profiles' into the repository. When a developer clones the repository, they can choose to enable the sparse profile for their particular product."
— Sapling announcement post
Four architectural properties flow from the "profiles live in the repo" choice:
- Profiles evolve with the code. As a product's dependencies change, the person changing them updates the profile, the same way they'd update any config file. No coordination with users of the profile.
- Every engineer on the profile picks up the update automatically on their next checkout / rebase. No manual reconfiguration; no "please update your sparse config" change-management dance.
- Review happens via normal PR / code review. Profile changes are diffable; reviewers can reason about blast radius.
- Scale: thousands of engineers on a shifting subset, zero per-engineer setup. Post-quote: "thousands of engineers to work on a constantly shifting subset of the repository without ever having to think about it."
Why this shape¶
The alternative — each engineer owns their sparse config — creates a reconfiguration tax that scales linearly with the number of engineers whenever the product layout changes. For a monorepo where product layouts change constantly, that tax is unacceptable.
Sparse profile-in-repo is the architectural move that shifts the sparse-checkout maintenance burden from the engineers to the organization — specifically, to the person making the dependency change that necessitated the config update.
Canonical wiki pattern: patterns/organization-owned-sparse-profile.
Seen in¶
- sources/2024-09-10-meta-sapling-source-control-thats-user-friendly-and-scalable — the canonical introduction; Meta's operational discipline for running sparse checkout across tens of thousands of engineers.
Related¶
- systems/sapling-scm — the implementation.
- concepts/sparse-checkout — the underlying mechanism.
- concepts/monorepo — the scale regime that demands this pattern.
- patterns/organization-owned-sparse-profile — the reusable wiki pattern.