Choosing Between svnserve and Apache HTTPD for Subversion Access

Decision: Choose Subversion Access Method

When setting up a Subversion server you must decide how clients will connect. The two main options are the lightweight svnserve daemon or Apache HTTPD with the mod_dav_svn module. This guide states the decision, lists constraints, compares the options, explains trade‑offs, and walks through a concrete Apache‑based implementation with validation steps.

Constraints

• Network environment: LAN-only trusted users vs. exposure to the internet or integration with existing web services.
• Authentication needs: simple password file vs. integration with LDAP, Active Directory, or complex path‑based authorization.
• Operational overhead: desire for minimal dependencies vs. willingness to run a full web server.
• Performance expectations: raw checkout/update speed vs. benefit from HTTP caching, keep‑alive, and virtual hosting.
• Feature requirements: web‑based repository browsing, proxying, or serving other web apps alongside SVN.

Option Comparison

Aspect	svnserve (standalone)	Apache HTTPD + mod_dav_svn
Protocol	TCP on port 3690 (custom svn:// or svn+ssh://)	HTTP/HTTPS on standard ports 80/443 (http:// or https://)
Dependencies	Subversion binaries only	Apache httpd, mod_dav_svn, auth modules, optional SSL
Authentication	Built‑in sasl or svnserve‑passwd file	Any Apache auth method (mod_auth_basic, mod_auth_ldap, mod_authz_svn for path‑based rules)
Web UI	None (requires external tools like ViewVC)	Built‑in directory browsing via mod_dav_svn
Performance	Lower per‑request overhead, good for raw checkout/update	Additional HTTP header processing; can benefit from keep‑alive and caching proxies
Firewall	Open TCP 3690	Open TCP 80 (HTTP) or 443 (HTTPS)
Typical use case	Small LAN, trusted users, minimal setup	Mixed environments, need for SSL, LDAP, web integration, granular authz

Trade‑offs

Choosing svnserve reduces attack surface and memory footprint but forces you to manage authentication separately and gives no native web browser view of the repository. Apache adds complexity and slightly higher CPU usage per request, yet it lets you reuse existing HTTPS infrastructure, enforce TLS, apply sophisticated AuthzSVNAccessFile rules, and serve the repository alongside other web applications without extra ports.

Concrete Implementation: Apache HTTPD with mod_dav_svn

The following steps assume a Debian/Ubuntu‑like system with root or sudo access. Adjust package names and paths for other distributions.

1. Install the required packages:

   sudo apt-get update
   sudo apt-get install apache2 libapache2-svn subversion

2. Create a directory to hold repositories (if not already existing):

   sudo mkdir -p /var/svn/repos
   sudo chown -R www-data:www-data /var/svn/repos

3. Create a sample repository:

   sudo svnadmin create /var/svn/repos/myproj
   sudo chown -R www-data:www-data /var/svn/repos/myproj

4. Enable the Subversion DAV module and restart Apache:

   sudo a2enmod dav_svn
   sudo systemctl restart apache2

5. Edit the Apache configuration to expose the repository. Create or edit /etc/apache2/sites-available/svn.conf with:

   <Location /svn>
       DAV svn
       SVNParentPath /var/svn/repos
       AuthType Basic
       AuthName \"Subversion Repository\"
       AuthUserFile /etc/apache2/dav_svn.passwd
       Require valid-user
   </Location>

6. Create the password file (first user):

   sudo htpasswd -c /etc/apache2/dav_svn.passwd alice
   # add more users without -c flag as needed
   sudo chown www-data:www-data /etc/apache2/dav_svn.passwd
   sudo chmod 640 /etc/apache2/dav_svn.passwd
   

7. (Optional) Set up path‑based authorization. Create /etc/apache2/authz_svn:

   [/]
   alice = rw
   [myproj:/trunk/doc]
   bob = r
   [myproj:/]
   * = r
   

   Then add to the Location block:

       AuthzSVNAccessFile /etc/apache2/authz_svn
   

8. Verify Apache syntax and reload:

   sudo apache2ctl configtest
   sudo systemctl reload apache2

Validation Steps

1. Check that Apache is listening on the expected port:

   sudo ss -tlnp | grep ':80'
   

2. Test read access via HTTP (no credentials needed if you allowed anonymous reads; otherwise provide a user):

   svn list http://host/svn/myproj
   

3. Test write access with a user that should have permission:

   svn mkdir --username alice --password alicepass \\\\n  -m 'Create test directory' http://host/svn/myproj/testdir
   

4. Test a denied write attempt (e.g., user bob trying to write to trunk):

   svn mkdir --username bob --password bobpass \\\\n  -m 'Should fail' http://host/svn/myproj/trunk/bad
   

5. Review Apache error log for any startup or request issues:

   sudo tail -f /var/log/apache2/error.log
   

Limitations and Practical Checks

• If you choose svnserve instead, remember to open TCP port 3690 on firewalls and consider tunneling over SSH for encryption.
• When using Apache, keep the versions of mod_dav_svn and the Subversion client/server in sync; a mismatch can produce 405 Method Not Allowed errors on PUT or MKCOL requests.
• Basic authentication over HTTP transmits credentials in plain text; always pair it with TLS (HTTPS) for production use.
• To confirm that the repository is truly accessible from a client machine, perform a fresh checkout in a clean workspace:

  svn checkout http://host/svn/myproj /tmp/myproj-wc