Subversion 1.14 Timeout Directive and Client Retry Behavior

Answer first

Subversion 1.14 core does not provide a unified automatic retry policy for server-enforced timeouts, and the Timeout directive is not a Subversion 1.14 feature for svnserve. Retry decisions remain with higher-level wrappers. Exposing a distinct API error code for timeouts and implicitly enabling retry in --non-interactive mode would be a change in client library behavior, not current 1.14 behavior. Wrappers should not assume a built-in retry exists and should base their own retry logic on the access method and observable timeouts.

Confirmed facts from 1.14

• Apache httpd mod_dav_svn: the Timeout directive is Apache core, not Subversion specific. It controls how long Apache waits for a request to complete and for idle connections, and it applies to all DAV requests including svn.
• svnserve: Subversion 1.14 has no Timeout directive in svnserve.conf. Runtime timeout control is not configurable via the config file. Startup behavior is influenced by OS socket timeouts and the svnserve --listen-timeout option, which is not a config directive.
• Client 1.14: the client library does not implement automatic retry on network errors or timeouts. A timed-out operation returns an error and must be manually reissued by the user or an external wrapper.
• Client HTTP wait time: can be tuned via the config option http-timeout in the clients config file, typically ~/.subversion/config, or via --config-option. This sets socket read timeout for http/https access.

Likely explanation vs uncertainty

Likely explanation: observed retries or intermittent hangs are usually from external tooling, shell wrappers, or Apache KeepAlive/Timeout interactions, not from built-in Subversion client retry logic.

Uncertainty for review: the question mentions an automatic retry when non-interactive flag is combined with a --retry option added in 1.13 and a separate error code for timeouts. The research brief used for planning indicates no built-in automatic retry in client 1.14 and does not confirm a distinct timeout error code separate from generic cancellation handling. Distinguishing user-initiated abort from a server timeout and the safety of transparent retry for a working copy are open design questions and require current verification.

Steps needed for this case

1. Identify access method. Check repository URL scheme. svn:// indicates svnserve, http:// or https:// indicates Apache httpd mod_dav_svn. This changes which timeout controls apply.
2. If Apache: on the host, inspect httpd.conf and included files for Timeout directive and the <Location> block for mod_dav_svn to confirm current value. Changing Apache Timeout affects all virtual hosts on that instance, not only Subversion.
3. If svnserve: confirm no Timeout directive is expected in svnserve.conf. Do not add one; it will be ignored.
4. On client, run svn --version to confirm 1.14 and inspect ~/.subversion/config for http-timeout under [network] to verify client timeout setting.
5. Reproduce with a controlled svn info or svn update and capture error message and timing to distinguish server Timeout from client http-timeout.

One missing diagnostic detail that changes the recommendation: the repository URL scheme and whether the client is using http/https or svnserve. Without that, timeout controls and retry safety cannot be scoped correctly.