Piper is acentralized version control system used byGoogle for its internal software development. Originally designed forLinux, it supportsMicrosoft Windows andmacOS since October 2012.[1]
Since its founding years Google has used a centralcodebase.[2] For over 10 years, Google relied on a singlePerforce instance, using proprietary caching for scalability.[3] The need for further scaling led to the development of Piper.[4] Currently, Google's version control "is an extreme case":[5] as of 2016,[update] the repository was storing 86terabytes of data comprising two billionlines of code in nine million files (twoorders of magnitude more than in theLinux kernel repository). 25,000 developers contributed 16,000 changes daily, with an additional 24,000commit operations by bots. Read requests each day are measured in billions.[6]
Piper uses regularGoogle Cloud storage solutions, originallyBigtable and laterSpanner, distributed across 10 data centers worldwide and replicated through thePaxos protocol.[3]
When using Piper, developers apply changes to a local copy of files, similar to aworking copy inSubversion,local clone inGit, or aclient in Perforce. Updates made by other developers can bepulled from the central repository and merged into the local code. Commits are only allowed after a code review via the Critique tool.[7][8]
Typical use involvesClients in the Cloud (CitC). This system utilizes cloud backend and a localFUSE filesystem to create an illusion of changes overlaid on top of a full repository. This approach enables seamless browsing and use of standard Unix tools without explicit synchronization operations, thus keeping the local copy very small (average size of a local copy is less than ten files). All file writes are mapped tosnapshots thus permitting restoration of the previous states of the code without explicit snapshotting. Due to its always-connected operation, CitC allows easy switching of computers, as well as sharing modified code with other developers, and use of the automatedbuild system and testing tools.[7] As a result, the majority of Google developers practicestrunk-based development with no personalbranches; the branches are mostly used for releases.[9]
Most of the codebase is visible to all developers, sensitive individual files (less than 1% as of 2016) are access-controlled. All operations with Piper are logged; accidentally committed files can be purged.[7]
