Diagnosing Slow Subversion Checkouts: Is Packing or Access Layer the Culprit?

Answering the Core Question

The primary determinant of checkout latency in an FSFS repository is typically the delta reconstruction process, which operates independently of the access layer. However, the access layer (svnserve vs. mod_dav_svn) contributes measurable overhead that becomes significant when network latency is low.

Confirmed Facts

• FSFS packing directly affects read amplification: When revisions are stored in large packed files, the server must read and parse more data to extract specific revisions, increasing disk I/O.
• mod_dav_svn incurs XML/HTTP overhead: This access layer adds serialization and parsing costs that svnserve avoids with its binary protocol.
• Checkout latency is dominated by sequential delta-chain traversal: The FSFS backend reconstructs file versions by applying deltas, and this process is disk-bound rather than network-bound.

Isolation Steps

1. Compare access layers: Checkout the same revision using svn:// (svnserve) and https:// (mod_dav_svn). If svnserve is significantly faster, the access layer is a contributing factor.
2. Local loopback test: Run the checkout from the server itself to eliminate network latency and isolate server-side processing.
3. Measure server-side I/O: Use strace on the server process during checkout to identify time spent in read() (disk I/O) versus socket operations (network/processing).

Missing Diagnostic Detail

To refine this analysis, please provide the FSFS format version (found in the repository's format file). Versions 1.6+ use representation-based storage, which changes how packing impacts read amplification compared to older skip-based formats.