(upbeat music)

- Hi there, I'm Muir Manders,

a software developer on the
source control team at Meta.

(upbeat music)

First, I think it's useful

to start with a definition
of source control.

Source control is the practice

of tracking changes to source code.

Fundamentally, source control helps

software developers read,
write, and maintain source code.

Another way to think about it

is source control helps
developers collaborate

by sending and receiving
changes with other developers

and by tracking different
branches of work.

Source control also provides
critical metadata to developers

so that they can understand

when and why source code has changed.

Now, looking at the current
landscape of source control,

I think it's safe to say
that it's dominated by Git.

Git is popular for a reason,

it does a lot of things right.

But when the Sapling
project first started,

Git didn't quite meet
our scalability needs.

(upbeat music)

As I mentioned before,
initially scalability

was the primary focus
of the Sapling project.

To keep up with the pace of
code growth over the years,

we've redesigned many aspects
of our source control system.

One of the key elements to our
scalability is lazy fetching.

By lazy, I mean that
Sapling doesn't fetch data

until it's needed.

For example, file history and
the commit graph are both lazy

and more than just the repo
data behind the scenes,

your working copy is lazy as well.

We use a virtualized file system

to defer fetching of files
contents until it's accessed.

Together, this means you can clone a repo

with tens of millions of
files in a matter of seconds.

It also means that giant
repo can fit on your laptop.

There is a catch with the laziness.

You must be online to perform

many source control operations.

This trade-off is worth it for us

but it may not be worth
it for smaller repos.

Beyond scalability, we've focused a lot

on the user experience.

We aim to hide unnecessary complexity,

while providing a rich set of
tools right out of the box.

A good example to start with is undo.

Just like in any software,
when you make a mistake,

or you just change your mind,

you wanna undo your changes.

In Sapling, undoing most operations

is as easy as "sl undo".

Undo demonstrates how Sapling

has developed first-class
integrated concepts

that improve the developer experience.

In the same vein as undo,

but perhaps even more core to Sapling

is the concept of stacked commits.

A commit stack is a
sequence of local commits

similar on the surface to a Git branch.

Commit stacks differ from Git
branches in two main ways.

First, a Git branch is essentially

a name that points to a commit.

With a sapling stack,
there is is no indirection,

the stack is the set of commits.

What does that mean?

For one, you don't even have
to give your stack a name

if you don't want,

and if you check out a commit
in the middle of the stack,

you're still on your stack,

and you can use normal
commands to amend that commit.

Another difference between sapling stacks

and Git branches is that stack commits

don't have to be merged all or nothing.

As early commits in your stack

are being code reviewed and merged,

you can continue pushing more commits

to that same line of work.

Similarly, if you push a
large stack of commits,

you can incrementally
merge the early commits

while you continue to
iterate on the later commits.

(upbeat music)

In November, 2022, we
released the Sapling client

which is compatible with Git repos.

To try it out, go to sapling-scm.com

and follow the instructions
to install the Sapling client

and clone an existing Git repo.

There's a couple other cool
things I want to mention.

On the website, under the add-on section,

you can see that Sapling

comes with a fully featured GUI

called the Interactive Smartlog,

it's really a game changer.

It's a high level UI that
hides unnecessary details

while still given the user powerful tools

like drag and drop rebase.

Also, we've released a proof of concept

code review website called ReviewStack

that's designed for the
stacked commit workflow.

Finally, I'd like to note

that the Sapling client is just one piece

of Meta's source control system.

In the future, we hope to release

our virtualized file system
and our server implementation.

Together, these three
integrated components

really take source control scalability

and developer experience
to the next level.

If you wanna learn more about Sapling

please visit sapling-scm.com.

If you're interested in
getting involved directly,

please check out our GitHub project page,

we welcome contributions.

(upbeat music)