This content has moved - please find it at

Although these pages remain accessible, some content may not display correctly in future as the new blog evolves.


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.

An example of a repository using an older file format

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

    Initiating an upgrade via VisualSVN Server

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

    Take note if you need to revert to an older version of SVN

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

    A simple and painless upgrade

  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.

    The properties of the same repository after upgrading

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.

Comparing the changed made by the upgrade

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

    Initiating a repository import

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

    Choosing the source to import from

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

    Selecting a SVN dump to import

  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

    Specifying the repository name

    An example error if your name isn't suitable

  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

    Setting the permissions for the new repository

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

    A slowly moving progress bar as the dump is imported

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

    A summary screen for a successful import

  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

About The Author


The founder of Cyotek, Richard enjoys creating new blog content for the site. Much more though, he likes to develop programs, and can often found writing reams of code. A long term gamer, he has aspirations in one day creating an epic video game. Until that time, he is mostly content with adding new bugs to WebCopy and the other Cyotek products.

Leave a Comment

While we appreciate comments from our users, please follow our posting guidelines. Have you tried the Cyotek Forums for support from Cyotek and the community?

Styling with Markdown is supported