This guide will walk through an approach that helps engineers upgrade subversion servers.

Though subversion’s popularity has declined in favor of Git over recent years, it’s still used in game or hardware companies as it could provide simplified large file management and folder-grained permissions.

Unlike upgrading Gitlab with pre-built scripts, problems arise when engineers try to upgrade subversion servers, as the lack of out-of-box free and open source platforms. They are required to upgrade the operation systems, HTTPD instances, and subversion binary files manually.

Background

Before getting started, it’s essential to understand the internal schema and structures of a subversion repository.

How does subversion store data and metadata?

After creating a subversion repository using svnadmin create <repo_name>, a folder is generated with the following structure.

• conf: the default location that stores the authz file and other secrets, our team chooses elsewhere in Apache’s conf as we have persistent the permissions into a database rather than modifying through manual configuration.

• db: Subversion data and metadata, which is managed by the FSFS schema, where internal structures could be found at apache document. We’ll use dump & load to migrate them from old schema(fsfs4/6/7) into the latest schema(fsfs8)

  • revs/revprops: the data and metadata.
  • Locks: the locks which can be found via svnadmin lslocks

• hooks: unrelative to the upgrade, remember that the hooks won’t get transferred while using dump & load migration.

• locks: unrelative to the upgrade.

Subversion file system schema comparability matrix

The diagram here shows the comparability matrix of FSFS schema.

Subversion binary keeps comparability with unupgraded repository remained. However, if you need better performance, less disk consumption and more features, you may upgrade the repository schema as well.

For instance, if the existing subversion server is 1.6 with fsfs4 repositories, two choices could be applied for the upgrade

• Only update subversion binary files from 1.6 to 1.14.
• Besides the binary upgrade, reload the repository file into the fresh fsfs8 schema.

Relationship between dump, load, and upgrade

In the svnadmin document, three commands can be used for the upgrade

• Dump: dump the repository into a fsfs4 formatted stdout stream, the stdout can also be dumped into a file with 2x larger disk space consumed.
• Load: load the dump file or stdin into the new repository.
• Upgrade: there is an ambiguity in the document, the command upgrade is not a in-place upgrade, it just updates the metadata flag of the existing repository without the internal file restructured, which is not recommended.
• Dump & load pipe: It’s the best solution to upgrade the schema without large space consumed. Commands are invoked in piped operation svnadmin dump [existing_repo] | svnadmin load > [new_repo]. Furthermore, a ssh piped tunnel could be applied between two machines.

Upgrade Steps

With the liability accumulated, it’s too late to implement an in-place upgrade, we have to create a new machine and migrate the data from one to another.

There are strategies for approaching the step-by-step migration. I hope that you get some new inspirations for how you manage the risks and complexity during the repository migration.

Outlink

• (Optional) Setup CName/ELB if there needs a migration between machines.
• (Optional) Upgrade the operation system from CentOS to Rocky9 or something else with a fresh installation, as CentOS7 will have EOL in June 2024.
• Upgrade the subversion binary file to 1.14.x using yum or free wandisco certificated subversion.
• (Optional) Upgrade Apache httpd instance to the latest version 2.4.x using yum.
• (Optional) Upgrade the subversion repository schema to fsfs8 using dump and load.

CName/ELB Setep

If the existing httpd service is behind an ELB/VIP or managed by a domain server, an IP address switchover is required during the migration.

Upgrade subversion binary file

I’d recommend using the free wandisco certificated subversion, as it is fully tested and provides the latest bug fix. It could be too late to wait for the release of OS packages.

Upgrade Apache httpd

• Install or compile the latest Apache httpd.
• Migrate httpd conf grammar if the ancestor instance is httpd 2.2.x
• Configure the location of mod_dav_svn.so inside the subversion binary.

Upgrade FSFS schema

Upgrading FSFS requires downtime.

• Verify existing repositories with svnadmin verify and svnadmin lslocks
• Create the new repo with a dump & load piped script.
• [With Downtime] Stop the old server and resynchronize the delta data with the piped script again.
• [With Downtime] Copy the lock into the new location, or skip the lock migration if they are no more used by users .
• [With Downtime] Verify the new repositories again with svnadmin verify and svnadmin lslocks.
• Start the new server.
• Switch the DNS/ELB to the new server.

Summary

It’s a giant process if the servers haven’t been upgraded for decades. As a result, implementing the migration requires patient and enumerative checklists.

Paid Solution

If you are unfamiliar with the maintenance of subversion, I’d recommend approaching a customer success team.

• WANdisco SVN MultiSite Plus
• Visual SVN