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 overview

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.

Upgrade Steps

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.

Initial synchronization

Upgrading FSFS requires downtime.

• Verify existing repositories with svnadmin verify and svnadmin lslocks
• Create the new repo with a dump & load piped script, accomplish the first full dump & load, verify the repositories with svnadmin verify and svnadmin lslocks. You will get the lastest shema.
• Send mails to users to help users know there will be a scheduled maintainence.

Incremental synchronization

• [With Downtime] Stop the old servers, or make it readonly (our solution).
• [With Downtime] 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 locked by users .
• [With Downtime] Verify the new repositories again with svnadmin verify and svnadmin lslocks.
• Start the new server.

DNS switchover

Switch the DNS/ELB to the new server.

If users are accessing the server via a hardcode IP/hostname that can’t be switched , it’s necessary to configure a reverse proxy on the old instance after the migration, so that jobs such as Jenkins build or Master-slave synchronization continues serves well.

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

Apache Httpd Security Tips

As the apache is famous for its vulnerability, here is the checklist to make the server safer

• Hide Apache version: using ServerTokens Prod and ServerSignature Off to hide your OS and apache version.
• Follows the guide.