SVN Server vs SVN Client: Resolving Concurrent Commit Latency under FSFS

SVN Server vs SVN Client: Concurrent Commit Latency

The goal is to understand how Subversion’s FSFS repository handles multiple simultaneous commit requests while a client performs concurrent read operations. The repository uses a single global write lock, which may serialize commits and cause latency spikes. The behavior differs between the svnserve daemon and Apache httpd with mod_dav_svn, which can spawn separate threads or processes per request.

Current evidence indicates that under Subversion 1.10 and later, the global lock still dominates commit performance, especially when read and write traffic overlap. An unresolved community decision is whether to replace this lock with finer‑grained mechanisms such as per‑transaction or per‑directory locks.

What is the quantitative impact of the global FSFS write lock on commit latency when multiple clients issue commits concurrently? How does svnserve compare to mod_dav_svn in handling mixed read/write loads? Would a per‑transaction or per‑directory lock reduce latency, and what trade‑offs might arise from such a change?