can you speak to commit throughput of the sapling server? While there's tooling to make git scale better (like sparse checkouts) scaling commit throughput for automation is a pain.
Unfortunately we can't really talk too much about that at this point. I can say a lot of effort has gone in on the server side to optimize commit throughput though.
One example we mention in the blog post is that when you push, it doesn't actually need to be a fast-foward push (using Git terminology) to succeed. Our server can rebase the commit on top of the destination bookmark for you (with some limitations, like not merging file contents). This allows many people to push, and not have to race to rebase. Then we have substantial optimizations around the critical section of final-rebase-then-move-branch-forward, which yields pretty good throughput.
