Upgrading a SVN repository using VisualSVN Server

Although I use Git for anything open source we produce, all other code is still in a SVN repository. I use VisualSVN Server for the server side things. When upgrading it last week to the latest version, it mentioned that Apache SVN 1.10 had new compression options and it occurred to me that while I've upgraded working copy formats before, my SVN databases are probably still using whatever format they were created at. This article covers how to upgrade SVN repositories using the VisualSVN Server software.

Checking the version of a repository

According to the release notes, the current filesystem format version used by SVN is 8. We can either use the svnadmin info command to view the version, or via a GUI by right clicking a repository in the Visual SVN Server Manager, selecting Properties from the context menu then accessing the Details tab.

In the above example, my SVN Repository is at version 4, so a little bit out of date. This particular repository was created in June 2011 using whatever version of VisualSVN Server was current at the time.

Upgrading a repository

There are two ways of upgrading the repository. The first is a simple action that doesn't change any existing commits; they remain in whatever format they were created with. Only new commits will use the features of the new format.

The second approach essentially recreates the repository from a backup, and rewrites everything using the new format.

Warning! If you upgrade the repository format, then you won't be able use this repository with older versions of SVN Server.

---

Important! Make sure you have backups before following either of the processes in this article, especially the latter

Upgrading the easy way

To perform a basic upgrade:

1. Right click the repository to upgrade, and select All Tasks from the context menu, then Upgrade Repository Format...

   

2. A confirmation prompt will be displayed, accept it to continue

   

3. In my case, the "upgrade" was instantaneous and a completion message was quickly displayed

   

4. When checking the properties for the repository, we can now see that the Filesystem format is 8, and the Compression is lz4. So the upgrade seems to have done something.

   

I was curious what the upgrade process had really done, so I compared the upgraded repository with a copy I'd made of the original.

Out of the 20 thousand (with spare change!) files making up the repository, only two had changed. The format file had a change from 4 to 8, very logical. The uuid file had a new entry added to it, which I assume is for new commits.

After I did the compare, I checked out the repository to a clean working copy, created a new file, then committed it. I then repeated the compare and could see the new transaction in the repository. No idea if it's using the new format or not though.

This was as far as I went with the basic upgrade. I checked that it seemed to be working as expected, but then reverted to my backup.

Upgrading the harder way

The second option isn't really an upgrade, or at least the approach I took wasn't. It basically involves creating a new repository by importing a dump of your current repository, which I assume upgrades as it goes.

I'm not covering how to create a dump file in this article - I'm going to assume that you are properly backing up your SVN repository already!

1. Right click the repositories root node and select Import Existing Repository... from the context menu

   

2. When prompted for a source, select the second option, Load repository from a dump file, and click Next

   

3. Enter the name of the SVN dump to import, then click Next

   

4. Next you need to specify a name for the repository, it will default to one based on the filename of the dump. However, it doesn't sanitise this default name and so you might find it it invalid

   

   

5. The last step is to set the permissions. The default seemed a little restrictive and weren't appropriate for my scenario, I went with No specific permissions (global permissions apply) to use the NTFS permissions I have set up on the repository folders. Make sure the permissions you set match those of the repository you're upgrading, then click Import to start the process

   

6. Wait for the import to complete. This make take some time.

   

7. Once it's finished, a summary dialog will be displayed

   

8. Exit the VisualSVN Manager

9. Stop any running VisualSVN services

10. Open the folder where your repositories are located

11. Rename your current repository

12. Rename the import repository to have the name of the original repository

13. If you have created custom hooks, you'll need to copy these from the hooks folder of your original repository. If you have customised other settings you may need to copy these too, however as I've always used default settings this didn't apply to me and so I don't know what files you'd need to modify

14. To stop VisualSVN Server from seeing the renamed original repository, you may wish to move it to a different location, until you are sure you don't need it and it is safe to delete

15. Restart the VisualSVN services that stopped previously

Once again, I performed a compare of the repository to try and get a feel for what the upgrade process does. Unfortunately, importing the dump file seems to re-order files within each transaction and so every single file was different even without looking for anything format specific. In all honesty, I couldn't see anything special about any change when looking at a sample of files.

One thing I did note was that the new repository was 746MB in size, compared with 680MB previously. I wasn't really expecting the repository to be larger given it was supposed to be optimised, and using a different compression method which you'd assume was chosen as it gave better returns than the older one.

Which approach to take?

I don't really know which approach is better - the former is certainly quicker, whilst the latter should result in a more optimised. However, VisualSVN Server doesn't make the latter approach particular easy at all - it would be much simpler to do svnadmin load from a command window instead of jumping the hoops of creating a new repository and then replacing the old one with the new.

As always, your mileage may vary. As always this article might have errors, proceed at your own risk and make sure you have backups!

Update History

• 2018-08-07 - First published
• 2020-11-22 - Updated formatting

---

Like what you're reading? Perhaps you like to buy us a coffee?

---