How To Install Apache Subversion on Debian 13

You just lost an entire week of development work because someone overwrote a critical file with no way to recover it. This nightmare happens every day in teams that skip version control. Apache Subversion solves this problem by tracking every single change to your files, letting you roll back to any previous state instantly.

This guide shows you how to install Apache Subversion on Debian 13 from scratch. You will build a production-ready SVN server with Apache WebDAV, user authentication, and path-based permissions. By the end, you will have a fully functional repository that your team can use immediately.

Prerequisites

Before you start the Apache Subversion on Debian 13 setup, make sure your environment meets these requirements. Skipping this step causes errors later that waste hours of debugging time.

Operating System: Debian 13 “Trixie” (stable release from August 2025)
User Access: Root user or a non-root user with sudo privileges
Apache 2.4: Either pre-installed or ready to install during this tutorial
Network: Static IP address or domain name for remote repository access
Terminal Skills: Basic familiarity with Linux commands and a text editor like nano or vim
Memory: At least 512 MB RAM (SVN is lightweight, but Apache needs headroom)
Storage: Minimum 2 GB free disk space for repository data and logs

You need these prerequisites because SVN depends on Apache as its web server. Without proper permissions, the installation will fail halfway through. The static IP ensures your team can connect consistently without DNS issues.

Step 1: Update Your System Package Index

Before installing new software, you must synchronize your system with Debian’s latest package repositories. This step prevents dependency conflicts and ensures you install the most secure versions.

sudo apt update && sudo apt upgrade -y

The apt update command downloads the latest package metadata from Debian mirrors. Without this synchronization, your system does not know that SVN version 1.14.5 exists in the Trixie repositories. You might install an outdated version or encounter “package not found” errors.

The apt upgrade -y command installs all available security patches for existing packages. Debian 13 released in August 2025, but patches for OpenSSL and Apache libraries have been released since then. Installing SVN on an unpatched system risks dependency conflicts when SVN tries to link against older versions of these libraries.

Expected output:

Get:1 http://deb.debian.org/debian trixie InRelease [140 kB]
Get:2 http://deb.debian.org/debian trixie/main amd64 Packages [9820 kB]
Fetched 9960 kB in 2s (4980 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
23 packages can be upgraded. Running 'apt upgrade' to update them.

Wait for the upgrade to complete before moving to the next step. Interrupting this process can leave your system in a partially upgraded state.

Step 2: Install Apache2 Web Server

Apache acts as the host for your SVN repository. The libapache2-mod-svn module requires a running Apache instance to function, so you must install Apache first.

sudo apt install -y apache2
sudo systemctl enable --now apache2

The apt install -y apache2 command installs the Apache HTTP Server version 2.4 without prompting for confirmation. The -y flag automatically answers “yes” to all prompts, speeding up the installation process.

The systemctl enable --now apache2 command does two critical things at once. The enable part configures Apache to start automatically when the server boots. The --now flag starts Apache immediately without requiring a separate command. Forgetting enable is the most common reason SVN becomes unreachable after a server reboot.

Verify Apache is running:

sudo systemctl status apache2

Expected output:

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2026-05-27 14:23:15 WIB
   Main PID: 12345 (apache2)
      Tasks: 7 (limit: 4915)
     Memory: 15.2M
     CGroup: /system.slice/apache2.service
             ├─12345 /usr/sbin/apache2 -k start
             └─12346 /usr/sbin/apache2 -k start

If you see active (running), Apache is ready. If you see failed or inactive, check the error logs with sudo journalctl -u apache2 -e.

Step 3: Install Apache Subversion and the SVN Module

Now you install the actual SVN software and the Apache module that exposes repositories over HTTP. This is the core of how to install Apache Subversion on Debian 13.

sudo apt install -y subversion libapache2-mod-svn

The subversion package provides the command-line tools you need to create and manage repositories. This includes svnadmin for repository initialization, svnlook for inspecting repository contents, and svn for client operations like checkout and commit.

The libapache2-mod-svn package provides two critical Apache modules: mod_dav_svn and mod_authz_svn. The mod_dav_svn module handles WebDAV protocol translation, allowing SVN clients to communicate with Apache over HTTP. The mod_authz_svn module enables path-based authorization, letting you restrict which users can write to specific directories. Without this module, Apache has no way to understand SVN requests.

Verify the installation worked:

svn --version

Expected output:

svn, version 1.14.5 (Debian packaging 1.14.5-3)
   compiled Feb 15 2026, 08:30:00 on x86_64-pc-linux-gnu

Copyright (C) 2026 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see https://subversion.apache.org/

The version number 1.14.5 confirms you installed the Debian 13 Trixie package. Do not use older SVN versions like 1.8 or 1.9, as they lack security patches and modern FSFS improvements.

Check that Apache loaded the SVN modules:

apache2ctl -M | grep dav

Expected output:

 dav_module (shared)
 dav_fs_module (shared)
 dav_svn_module (shared)

If dav_svn_module does not appear, the module did not load correctly. Run sudo a2enmod dav_svn and restart Apache.

Step 4: Create the SVN Repository Directory Structure

You now create the actual repository where your team will store code and files. This step initializes the database structure that SVN uses to track revisions.

sudo mkdir -p /var/svn/repos
sudo svnadmin create /var/svn/repos/project

The mkdir -p /var/svn/repos command creates the parent directory for all your repositories. The -p flag creates parent directories automatically, so you do not need to run separate commands for /var and /var/svn.

Why /var/svn/? The Linux Filesystem Hierarchy Standard (FHS) reserves /var for variable data that changes during normal operation. Storing repositories under /var/svn/ keeps them separate from web content in /var/www/ and makes backup scripts predictable. System administrators expect to find repository data in /var, not in your home directory.

The svnadmin create /var/svn/repos/project command initializes a complete SVN repository. This creates multiple subdirectories: conf/ for configuration files, db/ for the revision database, format for the database format version, hooks/ for server-side scripts, and locks/ for concurrency control.

Why FSFS format? Since SVN 1.8, the default backend is FSFS (File System File System). FSFS stores each revision as a plain file, making incremental backups with rsync straightforward. The older BDB (Berkeley DB) backend requires database-aware backup tools and can corrupt if the server crashes mid-commit. Debian 13 uses FSFS by default, so you get these benefits automatically.

Create the standard trunk/branches/tags layout:

sudo svn mkdir file:///var/svn/repos/project/trunk \
  file:///var/svn/repos/project/branches \
  file:///var/svn/repos/project/tags \
  -m "Initial repository structure"

This creates the conventional SVN directory structure. The trunk/ directory holds the main development line. The branches/ directory holds experimental work. The tags/ directory holds release snapshots. This layout is not enforced by SVN, but it is the industry standard that developers expect.

Expected output:

Committed revision 1.

The repository now has one revision containing the three directories.

Step 5: Set Correct File Permissions

Incorrect permissions are the leading cause of SVN server errors. If Apache cannot write to the repository, every commit attempt fails with a 403 Forbidden error.

sudo chown -R www-data:www-data /var/svn/repos/project
sudo chmod -R 775 /var/svn/repos/project

The chown -R www-data:www-data command changes ownership of the entire repository to the www-data user and group. Apache runs as www-data on Debian systems. When a developer commits code, Apache processes the request as www-data and needs write access to the db/ directory to record the new revision. Without this ownership, Apache cannot write changes.

The chmod -R 775 command sets read-write-execute permissions for the owner (www-data), read-write-execute for the group (www-data), and read-execute for everyone else. The execute permission on directories allows traversal, so users can navigate into subdirectories.

Why not 777? The chmod 777 command grants world-write access, allowing any process on the server to modify your repository. This violates the principle of least privilege and creates a security risk. If a web application vulnerability is exploited, the attacker gains write access to your version control data. The 775 setting restricts writes to www-data and its group members only.

Verify the permissions:

ls -la /var/svn/repos/project

Expected output:

total 44
drwxrwxr-x 5 www-data www-data 4096 May 27 14:35 .
drwxrwxr-x 3 www-data www-data 4096 May 27 14:34 ..
drwxrwxr-x 2 www-data www-data 4096 May 27 14:35 conf
drwxrwxr-x 4 www-data www-data 4096 May 27 14:35 db
-rw-rw-r-- 1 www-data www-data    5 May 27 14:35 format
drwxrwxr-x 2 www-data www-data 4096 May 27 14:35 hooks
drwxrwxr-x 2 www-data www-data 4096 May 27 14:35 locks

All entries should show www-data www-data ownership. If you see root root, the chown command did not work, and you must re-run it.

Step 6: Configure Apache2 for SVN WebDAV Access

This is the most critical step in configure Apache Subversion on Debian 13. You create an Apache configuration file that tells the server how to handle SVN requests.

Open the configuration file:

sudo nano /etc/apache2/conf-available/subversion.conf

Paste this configuration:

<Location /project>
    DAV svn
    SVNPath /var/svn/repos/project
    AuthType Basic
    AuthName "DAV SVN"
    AuthUserFile /var/svn/.svnpasswd
    Require valid-user
</Location>

The <Location /project> directive maps the URL path /project to this configuration. When a client requests http://your-server/project, Apache uses these settings. Do not use <Directory> here, because SVN repositories are not standard filesystem directories. <Directory> would cause Apache to return raw file listings instead of SVN responses.

The DAV svn directive activates the mod_dav_svn module for this location. Without this directive, Apache treats the location as a generic WebDAV endpoint. SVN clients cannot negotiate the correct protocol, and checkout commands fail immediately.

The SVNPath /var/svn/repos/project directive points to your repository directory. Apache uses this path to locate the repository when handling requests.

The AuthType Basic directive enables HTTP Basic Authentication. This is the simplest authentication method that disables anonymous access. Every request requires a username and password.

The AuthName "DAV SVN" directive sets the authentication realm name. This appears in the login prompt when users connect. Keep it simple and descriptive.

The AuthUserFile /var/svn/.svnpasswd directive specifies the password file containing user credentials. You will create this file in the next step.

The Require valid-user directive ensures only authenticated users can access the repository. Without this line, anyone can browse and commit, which is a critical security vulnerability.

Enable the configuration and required modules:

sudo a2enmod dav_svn
sudo a2enmod authz_svn
sudo a2enconf subversion
sudo systemctl reload apache2

The a2enmod dav_svn command enables the WebDAV SVN module. The a2enmod authz_svn command enables path-based authorization. The a2enconf subversion command enables your custom configuration file.

Why reload instead of restart? The systemctl reload apache2 command sends a SIGHUP signal to Apache, applying configuration changes without dropping active connections. Use restart only when loading new shared modules, since modules require a full process restart to load into memory. For simple configuration changes, reload is faster and safer.

Step 7: Create SVN Users with htpasswd

You now create authentication credentials for your team members. This step secures your repository against unauthorized access.

Create the first user:

sudo htpasswd -Bc /var/svn/.svnpasswd alice

When prompted, enter a strong password for the user alice.

Add additional users:

sudo htpasswd -B /var/svn/.svnpasswd bob

The htpasswd command manages the password file for Apache Basic Authentication. It is not related to system users in /etc/passwd, so these accounts have no shell access.

The -c flag creates a new password file. Use it only for the first user. If you use -c for subsequent users, it overwrites the existing file and deletes all previous users.

The -B flag uses bcrypt encryption for password hashing. The default htpasswd algorithm is MD5-apr1, which is outdated and vulnerable to brute-force attacks. Bcrypt is computationally expensive, making password cracking significantly slower even if the .svnpasswd file is leaked.

Set correct file ownership:

sudo chown www-data:www-data /var/svn/.svnpasswd
sudo chmod 640 /var/svn/.svnpasswd

The chown command ensures Apache can read the password file. The chmod 640 command allows the owner (www-data) to read and write, the group (www-data) to read, and everyone else to have no access. This prevents other local users from reading stored passwords.

Verify the file exists:

ls -la /var/svn/.svnpasswd

Expected output:

-rw-r----- 1 www-data www-data 142 May 27 14:40 /var/svn/.svnpasswd

Step 8: Configure Path-Based Authorization (Optional but Recommended)

Without path-based authorization, any authenticated user can commit to any directory. In real development teams, developers should not overwrite production tags or release branches.

Create the authorization file:

sudo nano /var/svn/repos/project/conf/authzsvn.conf

Paste this configuration:

[groups]
developer = alice, bob
operator = charlie

[/]
* = r

[project:/trunk]
@developer = rw

[project:/branches]
@operator = rw

[project:/tags]
@operator = rw

The [groups] section defines user groups. Group names start with @ in permission rules. This makes it easier to manage permissions when you add new team members.

The [/] section sets permissions for the repository root. The * = r rule grants read-only access to all authenticated users. Without this baseline rule, checkout commands fail with a 403 error even for authorized users, because they cannot read the directory tree.

The [project:/trunk] section grants read-write access to the developer group. Developers can commit to the main development line but cannot modify branches or tags.

The [project:/branches] and [project:/tags] sections grant read-write access to the operator group only. This enforces workflow discipline: only designated operators can create release branches or tag releases.

Add the authorization file to your Apache configuration:

sudo nano /etc/apache2/conf-available/subversion.conf

Add this line inside the <Location> block:

AuthzSVNAccessFile /var/svn/repos/project/conf/authzsvn.conf

Reload Apache:

sudo systemctl reload apache2

Path-based authorization is the key advantage of SVN over Git for enterprise environments. Git requires third-party tools like Gitolite to replicate this level of control at the directory level.

Step 9: Test the SVN Server via HTTP

Testing confirms that every previous step worked correctly. Skip this step at your own risk, because errors will surface later when your team tries to use the repository.

Test from the same server (loopback test):

svn list http://localhost/project --username alice

Enter alice’s password when prompted.

Expected output:

branches/
tags/
trunk/

Test from a remote client machine:

svn checkout http://your-server-ip/project myproject --username alice

Replace your-server-ip with your server’s actual IP address or domain name.

Why test both local and remote? The loopback test confirms the Apache configuration and SVN module work correctly. The remote test confirms firewall rules, DNS resolution, and network routing are correct. Passing only the loopback test and assuming remote access works is a common mistake that causes support tickets hours later.

Test a commit operation:

cd myproject/trunk
echo "Hello from SVN" > test.txt
svn add test.txt
svn commit -m "Initial test commit"

Expected output:

A         test.txt
Committing to file:///var/svn/repos/project/trunk ...
Committed revision 2.

If the commit succeeds, your SVN server is fully operational.

Step 10: Enable Firewall Rules

If your Debian 13 server has UFW (Uncomplicated Firewall) enabled, you must allow HTTP and HTTPS traffic for SVN to be reachable from external clients.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw reload

Port 80 handles HTTP traffic, and port 443 handles HTTPS traffic. SVN over HTTP uses these standard web ports. If UFW blocks these ports, the repository is completely unreachable from external clients, even when Apache runs correctly.

Check firewall status:

sudo ufw status

Expected output:

Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)

If you see 80/tcp and 443/tcp with ALLOW, the firewall is configured correctly.

Security Hardening Best Practices

A basic installation works, but production environments require additional hardening. These steps protect your repository from common attack vectors.

Disable anonymous access completely. Your <Location> block must include Require valid-user. Never use Require all granted in production. Anonymous access allows anyone to read your code, which is unacceptable for proprietary projects.

Use HTTPS instead of HTTP. HTTP Basic Authentication sends credentials in base64-encoded plaintext. Anyone on the network can decode these credentials with basic tools. Install a Let’s Encrypt certificate and redirect all HTTP traffic to HTTPS. This encrypts both credentials and repository data in transit.

Rotate passwords regularly. Enforce a password rotation policy for all SVN accounts. Use bcrypt hashing (already covered in Step 7) to make password cracking computationally expensive.

Enable Apache access logging. Add this line to your <Location> block:

CustomLog /var/log/apache2/svn-access.log combined

This creates an audit trail of every checkout, commit, and authentication attempt. Security teams need this log to detect suspicious activity like repeated failed login attempts.

Restrict configuration directory permissions. Run this command:

sudo chmod 700 /var/svn/repos/project/conf/

The conf/ directory contains your authzsvn.conf file. If world-readable, any local user can enumerate all usernames and group memberships.

Automate repository backups with svnadmin dump. Create a backup script:

sudo svnadmin dump /var/svn/repos/project > /backup/project.svndump

Why svnadmin dump instead of rsync? The dump format is a complete, portable representation of the repository. You can restore it on any SVN version. Direct rsync on the db/ directory can produce a corrupt backup if a commit is in progress during the copy.

Troubleshooting Common Errors

Even experienced sysadmins encounter errors during SVN setup. These are the five most common issues and their solutions.

Error 1: 403 Forbidden on Checkout

Cause: Wrong directory ownership or missing Apache module permissions.

Solution:

sudo chown -R www-data:www-data /var/svn/repos/
sudo systemctl reload apache2

Verify ownership with ls -la /var/svn/repos/. All entries should show www-data www-data.

Error 2: Could not open the requested SVN filesystem

Cause: The dav_svn module is not enabled.

Solution:

sudo a2enmod dav_svn
sudo systemctl restart apache2

Check module status with apache2ctl -M | grep dav_svn.

Error 3: svn: E175013: Access forbidden

Cause: Path-based authorization rules block the user.

Solution: Review /var/svn/repos/project/conf/authzsvn.conf. Ensure the user is in the correct group and that group has rw permissions for the target path.

Error 4: htpasswd: command not found

Cause: The apache2-utils package is not installed.

Solution:

sudo apt install -y apache2-utils

The htpasswd command is not part of the main Apache package.

Error 5: Repository shows blank page in browser

Cause: Missing SVNListParentPath On directive.

Solution: Add this line to your <Location> block:

SVNListParentPath On

Reload Apache: sudo systemctl reload apache2

Conclusion

You now know how to install Apache Subversion on Debian 13 from end to end. You built a production-ready SVN server with Apache WebDAV, user authentication, path-based authorization, and security hardening. Your team can start using the repository immediately.

Version control is not optional for any team managing code, configuration files, or documentation. SVN’s centralized model makes auditing, rollback, and access control straightforward in ways that distributed systems complicate. You avoided the nightmare of losing work because someone overwrote a file without backup.

Your next steps as a system administrator:

Enable HTTPS with Let’s Encrypt to encrypt all traffic
Set up automated daily backups using svnadmin dump
Configure email notifications for commit events using pre-commit hooks
Document repository access procedures for new team members

This Linux server tutorial gave you the foundation to run SVN professionally. Apply these same principles to other version control systems, and you will build robust infrastructure that scales with your team.

[su_box title=”VPS Manage Service Offer” style=”bubbles” box_color=”#000000″ radius=”10″]If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal![/su_box]