This guide outlines an approach to upgrading Subversion servers.

Though subversion’s popularity has declined in favor of Git over recent years, it remains prevalent in gaming or hardware industries duo to its simplified large file management and folder-grained permissions.

Unlike the Gitlab upgrade, upgrading subversion servers requires deeper knowledge of operation systems, Apache configurations, and subversion repository structures.

Background

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

Subversion repository structure

When creating a repository using svnadmin create <repo_name>, the following directories are generated:

• conf: Stores the authz file and other secrets. Note: The authentication file are often managed by Apache’s httpd.conf in production.

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

  • revs/revprops: Stores the data and metadata.

• hooks: Custom scripts (won’t get transferred via dump/load).

• locks: The key-value storage that persists locks from users, you can track user locks via svnadmin lslocks.

Subversion file system schema compatibility matrix

The diagram here shows the compatibility matrix of the FSFS schema.

Subversion binary keeps compatibility with legacy schema. 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:

• Binaray-only upgrade: Update subversion binaries (e.g., from 1.6 to 1.14).
• Full upgrade: 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 or file.
• Load: load the dump file or stdin into the new repository.
• Upgrade: The document is ambiguous, the command upgrade is not an in-place upgrade, it just updates the metadata flag of the existing repository without the internal file restructured.
• 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, an SSH piped tunnel could be applied between two machines.

Upgrade overview

There are two upgrade approaches:

• the first is an in-place upgrade, which requires a rollback plan and is constrained by downtime.
• The second approach is migration, which involves creating a fresh node and retiring the old one; however, it requires additional temporary storage and computational resources.

In our deployment environment, with the liability accumulated, it’s too late to implement an in-place upgrade, we have to create new machines and migrate the source code from one to another, as well as permission, hook and lock files.

Analyse current deployment

Before the migration, we’d like to have a full understanding of the current subversion deployment.

• Networking: Visualize the current structure of the physical nodes and their relationship. Find out which processes are listening on the machine, and which ports are managed under the firewall.
• Storage: Calculate the storage usage of our repositories to help estimate the time consumption of the migration, and estimate the storage size prepared for the new location.

Migration outlook

Upgrading legency system always involves complex planning and strategic decision-making. Here are some key steps to help you approach the upgrade effectively.

• (Optional) Prepare a CName/ELB switchover plan if there needs a re-routing between machines.
• Prepare new machines for the subversion, I prefer installing with RockyOS.
• Install the new subversion(1.14.x with fsfs8) on the new machines using yum or free wandisco certificated subversion. You may dockerize the Apache and subversion into an all-in-one image.
• Install the Apache httpd instance to the latest version 2.4.x using yum.
• Migrate repository files using dump and load.

Upgrade Steps

CName/ELB Setep

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

Install 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.

Don’t forget to remove the embedded subversion in the operation system. Or you might create a repository with the legacy version.

Install Apache httpd

• Install the latest Apache httpd, or compile from the source.
• Migrate httpd conf grammar if the ancestor instance is httpd 2.2.x
• Configure the location of mod_dav_svn.so to make authz work.

Initial synchronization

During the dumpload, there is no downtime required. You may also write a parallel synchronization script if you have thousands of repositories.

• Verify existing repositories with svnadmin verify

• Create the new repo with a dump & load piped script, and accomplish the first full dump & load.

  • Create new repositories in the new machine: svnadmin create <YOUR_REPO>. You may check the fsfs shema with svn info.
  • Dumpload on the old machine, the persuade piped script is: svnadmin dump <OLD_REPO> | ssh svnuser@newnode "svnadmin load" >> <NEW_REPO>

• Verify the checksum of new repositories with svnadmin verify.

• Send emails to users to help users know the downtime window and the post-migration URLs.

Incremental synchronization [With Downtime]

• Stop the old servers, or make them read-only.
• Resynchronize the delta data with the piped script again.
• Copy the lock and hook folders from the old location into the new location, or skip the migration if they are no longer used by users.

Consistency checking [With Downtime]

It’s time to check the consistency between the two repositories. The following check involves the checksum validation of files, locks, and logs of a subversion folder.

• generate checksum of locks: svnadmin lslocks <YOUR_REPO> | sha1sum | head -c 40
• generate checksum of file treeview: svn ls -R file://<YOUR_REPO> | sha1sum | head -c 40
• generate checksum of commit logs: svn log file://<YOUR_REPO> | sha1sum | head -c 40

The checksum must be the same between the two nodes, if they are not the same, you need to retry the synchronization.

Start the new server

It’s believed that the new server is ready for users, we can turn off the old server and start the new one.

DNS switchover

Switch the DNS/ELB to the new server.

If users are accessing the server via a hardcoded IP/hostname that can’t be switched easily, 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 continue to serve 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 engage vendor support to reduce risks.

• 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: Use ServerTokens Prod and ServerSignature Off to hide your OS and Apache version.
• Network policy: Enable SSL encryption, and audit logging. Apply Network ACLs inside the subnet.
• Follow the guide.