In 2011, Dan Bloch, the tech lead on the Perforce admin team at Google, published “Still All On One Server: Perforce at Scalehttps://static.googleusercontent.com/media/research.google.com/en//pubs/archive/39983.pdf .” The paper described how Google’s source control system, servicing “over twelve thousand users” a day, still ran off of a single Perforce server, tucked away under a stairwell in Building 43 on its main campus.

Graphite.dev

Google migrated from Perforce to Piper, their custom-built version control system, over four years to handle the immense scale of their codebase. Perforce's single server was struggling with the load, motivating the shift. This migration was complex due to Perforce's deep integration into Google's engineering environment and included production dependencies. The switch to Piper reduced operational risks and paved the way for new systems. The effort reflects not just Google's resources, but its engineering resilience and innovation.

How Google migrated billions of lines of code from Perforce to Piper

It’s impressive how a two-year-old Google server scaled to this level:
<blockquote>
As of 2014, “approximately 15 million lines of code were changed in approximately 250,000 files,” every week. To put this into perspective this volume is equivalent to re-writing the 2014 Linux kernel from scratch… weekly, nine years after Linus had already had to grapple with the complexities of its size”
</blockquote>
This is also cool to see how different companies take different approaches: in the company where I work, we have approximately 30 thousand active repositories (excluding personal repositories)