Source Control at Scale: Diagnose the Bottleneck Before Building a Replacement

Slow source control is not one problem. Cloning, fetching, searching history, computing diffs, merging, and maintaining repositories stress different parts of a system. Measure the operations that are failing before deciding to replace the platform or invent a new source-control architecture.

Anthropic's October 13, 2026 engineering account of redesigning source control describes Scion, a distributed system developed for its growing repository and automation needs. The account discusses scalable data access and reducing the burden of maintaining repository copies. It is evidence about one company's constraints and design, not a general instruction for small teams to abandon Git.

Describe the actual failure

Record which operation is slow, who performs it, repository size and shape, network conditions, client version, server load, and time distribution. Separate a developer's first clone from a CI job's repeated fetch and an analysis tool's history query.

Measure median and tail latency, failures, resource consumption, and frequency. A rare slow clone may be inconvenient while thousands of repeated metadata requests create a larger total cost. Prioritize the bottleneck that affects delivery rather than the metric easiest to screenshot.

Keep a stable test case and environment. A comparison made on different networks or with different warm caches can misattribute an improvement to the source-control change.

Investigate repository shape

Review large blobs, generated files, history growth, binary assets, many references, and workflows that repeatedly copy the entire repository. Identify who owns each growth source and whether it belongs in source control.

Do not rewrite shared history casually to remove a large file. Existing clones, release tags, and audit evidence may depend on it. Choose a supported, reviewed migration if history changes are necessary, and preserve the mapping users need.

Separating generated artifacts from source can help, but verify reproducibility and availability of the replacement artifact store. Moving a problem to an unmanaged download location is not a dependable architecture improvement.

Measure automation amplification

CI and AI tooling can multiply repository operations. A job that starts a fresh full clone for every small task may consume more resources than developers do. Record how many clones, fetches, history walks, and searches a completed workflow requires.

Compare supported options such as reusing appropriate checkout state, limiting unnecessary history, or requesting only needed data. Each has semantics to verify: a shallow checkout may be unsuitable for a task that requires ancestry or version derivation.

Do not share a mutable working directory across concurrent jobs to save space. Separate checkouts or Git worktrees can help task organization, but their shared repository state still needs careful coordination.

Test changes against required operations

Build a benchmark suite around real tasks: initial checkout, incremental update, diff, merge-base query, release tagging, history inspection, and recovery after interruption. Include representative large files and branches.

Record correctness as well as speed. A faster process that omits files, loses history needed by a build, or produces the wrong version label is not an improvement. Verify release and artifact mappings after checkout changes.

Estimate total resource cost: storage, network, CPU, maintenance, and operator time. A cache may improve latency while adding invalidation and recovery responsibilities. Document how it is rebuilt and how users detect stale results.

Evaluate replacement costs explicitly

A new source-control system must support authentication, authorization, backups, recovery, client tooling, code review, integrations, release references, and migration. It also needs long-term ownership when the original authors leave or priorities change.

Consider a hypothetical replacement that saves twenty engineer-hours weekly but requires a dedicated team to operate and maintain it. The tradeoff may be justified at one scale and clearly inappropriate at another. Do not copy a large company's architecture without its workload and staffing assumptions.

Compare improving the current setup, buying supported capacity, narrowing repository scope, and building a replacement over the same time horizon. Include transition risk and the cost of maintaining both systems during migration.

Plan a migration without losing history

If replacement is justified, define how commits or changesets, references, authorship, permissions, release tags, and review links map. Test a representative migration before a full cutover. Identify which old URLs must remain usable and how users find corresponding records.

Keep a read-only historical path where appropriate and document the authority for new writes. Two writable systems without a clear synchronization contract can diverge silently. A rollback must address changes made after cutover, not merely restore yesterday's repository copy.

Make the decision proportional to the problem

Publish measured bottlenecks, tested improvements, remaining limits, cost, and operational ownership. Distinguish an engineering experiment from a supported platform. A promising prototype is not yet a replacement the whole company can depend on.

Source control should make correct changes easier to deliver and trace. Diagnose operation-level pressure first, then choose the simplest supported architecture that meets the workload. Large-scale redesigns are interesting evidence, but your own measurements should determine whether one is necessary.