Skip to content

CONCEPT Cited by 1 source

Virtual file system (for monorepo)

Virtual file system (VFS) for monorepo is a working-copy-layer primitive that presents the full repository shape to the filesystem (so user tools, build systems, and IDEs see what looks like a complete checkout) but fetches file contents lazily on first access and caches them locally thereafter. Clones and checkouts become near-constant-time regardless of working-copy size.

Canonical instances

  • Sapling VFS — Meta's (not-yet-open- sourced) VFS for Sapling. Post-quote: "makes it look and act as if you have the entire repository. Clones and checkouts become very fast, and while accessing a file for the first time requires a network request, subsequent accesses are fast and prefetching mechanisms can warm the cache for your project."
  • Microsoft GVFS / VFS for Git — 2017 Microsoft-internal system for managing Microsoft's Windows source tree on Git. Later rebranded Scalar.
  • Meta EdenFS — Meta's Sapling-era file system, referenced elsewhere in the broader Sapling ecosystem; Sapling VFS may be a direct descendant.

This wiki keeps the Sapling-specific implementation at systems/sapling-virtual-fs; this concept page covers the pattern class spanning all three.

Design properties

  • Presents full shape. Directory listings, file metadata, and file presence look identical to a complete checkout.
  • Lazy fetch on read. File contents are fetched from a server the first time any tool reads them.
  • Local caching. Subsequent reads come from the local cache; no network round-trip unless content changes.
  • Prefetch. Working-set warmup (per project, per user, per pattern) hides the first-access latency for common workflows.
  • Independent of VCS commands. checkout doesn't materialize files; it only flips the virtual shape. status, diff, commit go through the VFS as needed.

Cost model

Classical checkout: O(#files-changed) for checkout, O(#files-in-repo) for full clone.

VFS checkout: O(1) for the shape flip; O(#files-accessed) for the lazy reads, amortized over the developer's actual activity. Full cost of the repo is only paid for files actually used — a better fit for monorepos where a given engineer touches a small fraction.

When the VFS isn't available

Partial mitigations that deliver some of the benefit at less cost:

  • Sparse checkouts — materialize only a declared subset of paths. Sapling's fallback when the VFS isn't deployed.
  • Watchman — incremental file-change subscriptions so status-style queries don't re-scan the whole tree.

Seen in

Last updated · 319 distilled / 1,201 read