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 and opensource communities, upgrading subversion servers requires a full understanding of the operation systems, apache, and subversion instances.

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 choose elsewhere, which are included in Apache’s httpd.conf.

• db: Subversion data and metadata 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: Remember that the hooks won’t get transferred while using dump & load migration.

• locks: The key-value storage that persists locks from users.

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 or file. The file might consume 2x larger disk space.
• 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

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 transfer 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 current subversion deployment.

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

Migration outlook

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.

• (Optional) Setup CName/ELB swichover plan if there needs a re routing 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.
• Install the subversion binary file to 1.14.x using yum or free wandisco certificated subversion. You may dockerlize the apache and subversion into an all-in-one image.
• (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 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 legancy version.

Install 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 to make authz work.

Initial synchronization

During the dumpload, there is no downtime required.

• Verify existing repositories with svnadmin verify

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

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

• Verify the checksum of new repositories with svnadmin verify.

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

• [With Downtime] Resynchronize the delta data with the piped script again.

• generate checksums of existing repositories.

  • 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

• Rsync the lock into the new location, or skip the lock migration if they are no more locked by users.

• Verify the checksum of new repositories with previous commands.

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