svnserve+SSH minimal footprint vs mod_dav_svn per-path authorization for constrained Subversion deployment

Direct answer

For a resource-constrained host running Subversion 1.14+, svnserve over SSH with an authz-db file is the documented access model that satisfies per-path authorization without adding Apache or a full web server stack. The same path-based rule syntax used by mod_dav_svn is available natively in svnserve. As of the Subversion 1.14 documentation, svnserve remains a supported server; the project has not published an official deprecation roadmap replacing it with HTTP-only workflows.

Correcting the premise

The assumption that svnserve lacks per-path authorization is incorrect. In svnserve.conf, the authz-db directive points to an authorization file that supports rules such as [reponame:/path] with rw or r permissions. This is enforced by the svnserve process itself, not by an external web server.

Minimal configuration

1. In svnserve.conf under the [general] section, set authz-db = /etc/subversion/authz.
2. Create the authz file with path-scoped rules, for example [project:/trunk/confidential] and alice = rw.
3. Ensure the authz file and repository are readable by the connecting system user when using svn+ssh://.
4. Run svnserve as a daemon or let sshd spawn it per connection.

This avoids httpd worker processes entirely, keeping resident memory and scheduling overhead minimal.

When Apache is still necessary

If clients require HTTP/HTTPS transport, WebDAV capabilities, or browser-based repository browsing, mod_dav_svn with AuthzSVNAccessFile is required despite the additional process footprint.

Verification

# Test read access on a restricted path
svn list svn+ssh://host/repo/trunk/confidential

# Test read access on a public path
svn list svn+ssh://host/repo/trunk/public

An unauthorized user should receive an authorization failure on the restricted path.

Maintenance status and uncertainty

No official deprecation roadmap for svnserve has been published in the Subversion 1.14+ documentation reviewed here. However, support status and release schedules are time-sensitive; verify against the latest Apache Subversion release notes before finalizing a long-term deployment.

One diagnostic detail that changes the recommendation

Do your clients need HTTP/HTTPS access or web-based repository browsing? If yes, the recommendation shifts to mod_dav_svn. If no, svnserve with authz-db is the lower-footprint, documented choice.