How to Install Apache Subversion on Ubuntu 26.04, 24.04 and 22.04

Subversion still fits teams that need a central repository, path-based authorization, or compatibility with older SVN workflows instead of a distributed Git model. Install Apache Subversion on Ubuntu from the Universe package to get the svn client, repository administration commands, and the svnserve network server in one APT-managed package.

Apache is the project name here, not a requirement to install Apache HTTP Server. Local repositories and svn:// access use Subversion’s own tools; HTTP or HTTPS access requires Apache HTTP Server with libapache2-mod-svn, while Nginx alone is not a Subversion WebDAV backend.

Install Apache Subversion on Ubuntu

Ubuntu packages Subversion in the Universe component on supported LTS releases. The package branch stays on Subversion 1.14.x, while exact package revisions differ by Ubuntu release and security pocket.

Ubuntu Release	Default Subversion Branch	Archive Component	Installed Command Set
Ubuntu 26.04 LTS	1.14.x	Universe	svn, svnadmin, svnlook, svnserve, svnversion
Ubuntu 24.04 LTS	1.14.x	Universe	svn, svnadmin, svnlook, svnserve, svnversion
Ubuntu 22.04 LTS	1.14.x	Universe	svn, svnadmin, svnlook, svnserve, svnversion

Update APT Package Metadata

Refresh APT metadata so Ubuntu installs the current package revision from your enabled repositories:

sudo apt update

These commands use sudo for package-management tasks. If your account cannot use sudo, add an administrator account to sudoers on Ubuntu before continuing.

Install Subversion with APT

Install the Ubuntu repository package:

sudo apt install subversion

The subversion package installs the user-facing SVN client, repository tools, and svnserve. It does not create a running system service by itself, so a local workstation install is ready after the command finishes.

Verify Subversion on Ubuntu

Confirm that the expected Subversion commands are available, then print the installed client version:

command -v svn svnadmin svnlook svnserve svnversion
svn --version --quiet

Example output on Ubuntu 26.04 includes the installed command paths and the current 1.14.x client version:

/usr/bin/svn
/usr/bin/svnadmin
/usr/bin/svnlook
/usr/bin/svnserve
/usr/bin/svnversion
1.14.5

Create a Local Subversion Repository on Ubuntu

A local repository gives you a safe first-use check without configuring a network service. Keep the repository and working copy under your home directory for this example so normal user permissions handle file access.

Create the Repository and First Import

Create a repository named project1, prepare an initial trunk directory, and import the first file:

mkdir -p "$HOME/svn-repositories" "$HOME/svn-import/project1/trunk"
printf 'Subversion repository test\n' > "$HOME/svn-import/project1/trunk/README.txt"
svnadmin create "$HOME/svn-repositories/project1"
svn import -q -m "Initial import" "$HOME/svn-import/project1/trunk" "file://$HOME/svn-repositories/project1/trunk"

Check the newest repository revision after the import:

svnlook youngest "$HOME/svn-repositories/project1"

The first committed revision should be 1:

1

Check Out a Working Copy

Create a working-copy directory and check out the imported trunk:

mkdir -p "$HOME/svn-work"
svn checkout -q "file://$HOME/svn-repositories/project1/trunk" "$HOME/svn-work/project1"
svnversion "$HOME/svn-work/project1"

The working copy should report revision 1 because it was checked out from the initial import:

1

Commit a Test Change

Use the working copy to make one small change, confirm that Subversion sees it, then commit it back to the local repository. The final cd "$HOME" returns your shell to a safe location before later cleanup commands delete the example working copy:

cd "$HOME/svn-work/project1"
printf 'Second line\n' >> README.txt
svn status
svn commit -q -m "Update README"
cd "$HOME"
svnlook youngest "$HOME/svn-repositories/project1"

On the first run, svn status marks the edited file as modified and the repository revision advances to 2:

M       README.txt
2

Use Subversion After Installation

The installed command set covers normal client work, repository administration, and read-only repository inspection. The official Apache Subversion documentation is the best follow-up reference for repository layouts, access control, hook scripts, and server deployments.

Task	Command	What It Does
Check working-copy changes	svn status "$HOME/svn-work/project1"	Shows added, modified, deleted, and conflicted files.
Commit tracked changes	svn commit -m "Update README" "$HOME/svn-work/project1"	Sends working-copy changes to the repository with a log message.
Update a working copy	svn update "$HOME/svn-work/project1"	Pulls the latest repository revision into the working copy.
View repository history	svn log "$HOME/svn-work/project1"	Prints commit history visible from the working copy.
Inspect the repository revision	svnlook youngest "$HOME/svn-repositories/project1"	Reads the newest committed revision directly from the repository.

If you need shared network access, decide which protocol belongs to the deployment before opening ports. Use svnserve for the svn:// protocol, or use Apache HTTP Server with libapache2-mod-svn for HTTP and HTTPS access. Nginx can sit in front of Apache as a reverse proxy, but it does not replace the Subversion WebDAV backend.

Configure HTTP Access with Apache HTTP Server

Use Apache HTTP Server when SVN clients need http:// or https:// repository URLs. The Subversion Apache module handles the WebDAV protocol, while Apache’s normal authentication and TLS layers protect the repository. Use HTTPS before exposing Basic authentication beyond localhost; secure Apache with Let’s Encrypt on Ubuntu covers the certificate path.

Install the Apache Subversion Module

Install Apache HTTP Server, the Subversion DAV module, and the Apache utility package that provides htpasswd:

sudo apt install apache2 libapache2-mod-svn apache2-utils

The package set keeps HTTP SVN access under APT ownership. libapache2-mod-svn provides the Apache modules, while subversion still provides the repository tools and client commands.

Create an Apache-Served Repository

Create a repository under /srv/svn for the web-served example. The ownership change lets Apache’s www-data account read and write repository data for authenticated commits:

sudo mkdir -p /srv/svn
sudo svnadmin create /srv/svn/project1
sudo chown -R www-data:www-data /srv/svn/project1

Do not point Apache at the home-directory test repository from the earlier local example unless you deliberately move it and adjust ownership, backups, hook scripts, and service permissions for a shared deployment.

Create Authentication and Access Files

Create the first HTTP authentication user. The -c option creates the password file and truncates an existing file, so use it only for the first user:

sudo htpasswd -c /etc/apache2/svn-passwd svnuser

Add a compact path-authorization file that grants svnuser read/write access and denies anonymous access:

sudo tee /etc/apache2/svn-access-control > /dev/null <<'EOF'
[/]
svnuser = rw
* =
EOF

Add the Apache SVN Location Block

Create an Apache configuration file that maps URLs under /svn to repositories stored under /srv/svn:

sudo tee /etc/apache2/conf-available/subversion.conf > /dev/null <<'EOF'
<Location /svn>
    DAV svn
    SVNParentPath /srv/svn
    AuthType Basic
    AuthName "Subversion repositories"
    AuthUserFile /etc/apache2/svn-passwd
    AuthzSVNAccessFile /etc/apache2/svn-access-control
    Require valid-user
</Location>
EOF
sudo a2enmod dav dav_svn authz_svn
sudo a2enconf subversion
sudo apache2ctl configtest
sudo systemctl reload apache2

Confirm Apache is active after the reload:

systemctl is-active apache2

The command should print active:

active

Verify the HTTP SVN Repository URL

Use the Subversion client itself to verify the HTTP URL. Enter the password created with htpasswd when prompted:

svn info --username svnuser --no-auth-cache http://127.0.0.1/svn/project1/

A successful response prints repository details such as the URL, repository root, UUID, revision, and node kind. After local verification passes, open firewall access only for the network that should reach the SVN endpoint; configure UFW on Ubuntu if the host uses UFW.

Place Nginx in Front of Apache When Needed

Use Nginx only as the public reverse proxy or TLS endpoint. Apache must still serve the SVN repository through mod_dav_svn on a backend URL that Nginx can reach, often a loopback-only listener such as 127.0.0.1:8080. The direct Apache configuration earlier does not create that separate loopback listener by itself, so create or adjust an Apache virtual host for the backend before using the Nginx block. Do not point Nginx directly at /srv/svn; that bypasses the Subversion DAV layer.

After the Apache backend URL works locally, add this location block inside the existing Nginx server block for svn.example.com. Change the proxy_pass value if Apache listens on a different verified backend URL:

location /svn/ {
    proxy_pass http://127.0.0.1:8080/svn/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Check the Nginx syntax before reloading. Install and harden Nginx separately if it is not already the front-end web server; start with install Nginx on Ubuntu when the host does not have Nginx yet.

sudo nginx -t
sudo systemctl reload nginx

Update or Remove Apache Subversion on Ubuntu

Update Subversion with APT

APT updates Subversion with the rest of your Ubuntu packages. To refresh metadata and upgrade only an already installed Subversion package, use --only-upgrade:

sudo apt update
sudo apt install --only-upgrade subversion

The --only-upgrade option prevents APT from installing Subversion on a system where it is not already present.

If you installed HTTP access, Apache, libapache2-mod-svn, and apache2-utils also update through APT. Normal system upgrades keep those packages current with Ubuntu security and maintenance updates.

Remove Subversion Packages

Remove the package when you no longer need the Subversion commands:

sudo apt remove subversion

Use purge only when you also want to remove package configuration files managed by the Debian package:

sudo apt purge subversion

Package removal does not delete repositories, working copies, or import directories you created under your home directory.

Remove Apache SVN HTTP Access

Disable the optional Apache SVN configuration before removing the module package. Keep Apache itself installed if it serves other sites:

sudo a2disconf subversion
sudo rm -f /etc/apache2/conf-available/subversion.conf /etc/apache2/svn-passwd /etc/apache2/svn-access-control
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apt remove libapache2-mod-svn

If Apache HTTP Server was installed only for SVN access, remove Apache after confirming no other sites or local services depend on it. The dedicated Apache guide covers broader Apache package management on Ubuntu.

List any web-served repository path before deleting it:

sudo find /srv/svn/project1 -maxdepth 0 -print 2>/dev/null

The cleanup command permanently deletes the web-served SVN repository. Back up repository data, hook scripts, and access-control files before removing a shared repository path.

sudo rm -rf -- /srv/svn/project1

Remove the Example Repository Data

List the example paths before deleting anything:

find "$HOME/svn-repositories/project1" "$HOME/svn-import/project1" "$HOME/svn-work/project1" -maxdepth 0 -print 2>/dev/null

The cleanup command permanently deletes the example repository, import tree, and working copy. Back up any repository data you need before running it, and remove any path from the command that you want to keep.

rm -rf -- "$HOME/svn-repositories/project1" "$HOME/svn-import/project1" "$HOME/svn-work/project1"

Troubleshoot Subversion on Ubuntu

APT Cannot Locate the Subversion Package

Subversion lives in Ubuntu’s Universe component. Check whether APT can see a candidate package before repeating the install command:

apt-cache policy subversion

If the Candidate line shows (none), install the repository helper if needed, enable Universe, and refresh APT metadata:

sudo apt install software-properties-common
sudo add-apt-repository universe
sudo apt update

Repository Commands Fail with Permission Denied

Permission errors usually mean the repository path is owned by the wrong account or was created with sudo when it should have been user-owned. Inspect the repository directory first:

ls -ld "$HOME/svn-repositories/project1"

If the example repository should belong to your account, restore ownership to the current user:

sudo chown -R "$USER:$USER" "$HOME/svn-repositories/project1"

Do not apply that ownership fix to a shared repository served by Apache or another service account. Shared deployments need ownership and permissions that match the service model.

Checkout Cannot Connect to a Repository URL

Subversion URL schemes are not interchangeable. A local repository uses file://, svnserve uses svn://, and Apache HTTP Server with libapache2-mod-svn uses http:// or https://.

For the local example repository, prove the repository URL before checking out another working copy:

svn info "file://$HOME/svn-repositories/project1/trunk"

If an svn:// or HTTP(S) URL fails, check the server process, authentication layer, firewall, and URL path for that specific protocol instead of switching schemes at random.

Apache SVN Modules Are Not Loaded

An HTTP SVN URL cannot work until Apache loads the DAV SVN modules. Check the loaded module list first:

apache2ctl -M 2>/dev/null | grep -E 'dav_svn|authz_svn'

If the command prints no matching modules, enable the required modules, test the configuration, and reload Apache:

sudo a2enmod dav dav_svn authz_svn
sudo apache2ctl configtest
sudo systemctl reload apache2

Retest the HTTP repository URL after Apache reloads:

svn info --username svnuser --no-auth-cache http://127.0.0.1/svn/project1/

HTTP SVN Access Returns Forbidden

A 403 Forbidden response usually means Apache can reach the repository, but the access-control file or repository ownership blocks the authenticated user. Check the active access file and recent Apache errors:

sudo cat /etc/apache2/svn-access-control
sudo tail -n 40 /var/log/apache2/error.log

For the example repository, restore the basic read/write rule and reload Apache after a successful syntax check:

sudo tee /etc/apache2/svn-access-control > /dev/null <<'EOF'
[/]
svnuser = rw
* =
EOF
sudo apache2ctl configtest
sudo systemctl reload apache2

Retest the URL after the access file and ownership are correct:

svn info --username svnuser --no-auth-cache http://127.0.0.1/svn/project1/

Nginx Proxy Returns Bad Gateway for SVN

A 502 Bad Gateway response from Nginx means the front end could not reach the Apache backend. Prove the backend SVN URL locally before changing the Nginx proxy block:

svn info --username svnuser --no-auth-cache http://127.0.0.1:8080/svn/project1/
sudo nginx -t

If the local Apache URL fails, fix Apache, authentication, or the loopback listener first. If the local Apache URL works but Nginx still returns 502, correct the proxy_pass target, run sudo nginx -t, and reload Nginx only after the syntax check succeeds.

Conclusion

Apache Subversion is installed on Ubuntu with the main SVN client and repository tools verified from the APT package. A local repository is ready for workstation testing, and shared HTTP access can now be routed through Apache HTTP Server, with Nginx used only as an optional front-end proxy when that architecture fits the site.