Upgrading to VisualSVN Server 5.1

Verify that the operating system installed on your server is still supported

The step applies to an upgrade from VisualSVN Server 4.3 and older versions.

Starting from VisualSVN Server 5.0, the minimum supported operating systems are Windows Server 2012 R2 and Windows 8.1. You are required to upgrade your operating system or move your instance of VisualSVN Server to another computer if your current OS is no longer supported.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Do not uninstall the existing VisualSVN Server instance

You must not uninstall the existing VisualSVN Server instance before installing a newer version. VisualSVN Server is designed to be always installed over the existing version. Important server settings could be lost when you uninstall VisualSVN Server instance.

5.0; 4.3; 4.2; 4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Make sure that you have administrative permissions on the computer

The step applies to an upgrade from all VisualSVN Server versions. To upgrade successfully, you should start the VisualSVN Server installation package under account with administrative permissions.

5.0; 4.3; 4.2; 4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Verify that you do not use Internet Explorer to access the VisualSVN Server web interface

The step applies to an upgrade from VisualSVN Server 4.3 and older versions.

Starting from version 5.0, the VisualSVN Server web interface does not support Internet Explorer. If you use Internet Explorer to access the web interface, you are required to upgrade to Microsoft Edge or switch to another supported browser.

Note that the Internet Explorer 11 desktop application will go out of support (for certain operating systems) starting June 15, 2022. And Microsoft encourages customers to move to Microsoft Edge with Internet Explorer (IE) mode.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Check the TLS/SSL compatibility level settings (SSL 3.0 is no longer supported)

The step applies to an upgrade from VisualSVN Server 4.3 and older versions.

VisualSVN Server 5.0 drops support for the SSL 3.0 protocol (even if the Legacy TLS/SSL compatibility level is enabled). There will be no negative implications for almost all modern clients interacting with the server. However, outdated clients that do not support protocols newer than SSL 3.0 will be getting an access error upon the server upgrade. If you have such clients (e.g. clients based on Java 5 or older), you need to upgrade them beforehand.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Remove customizations related to MaxMemFree directive from httpd-custom.conf

The step applies to an upgrade from VisualSVN Server 4.3 and earlier versions that have customizations in the %VISUALSVN_SERVER%conf\httpd-custom.conf file.

VisualSVN Server 5.0 switched to a new memory allocation scheme without the MaxMemFree configuration directive. You should examine the httpd-custom.conf file and remove the following directive before upgrading to VisualSVN Server 5.0:

• MaxMemFree

4.3; 4.2; 4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Skip enabling search indexing in the installer if custom permissions are needed to access the repositories

The step applies to an upgrade from VisualSVN Server 4.3 and older versions.

If custom permissions are needed to access the repositories on your server (which often happens when repositories are stored on a network share and permissions are granted to the dedicated account), please skip enabling search indexing in the installer. For instructions on how to enable search indexing in this case, see the corresponding post-upgrade checklist entry.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Remove customizations related to mod_mpm_winnt from httpd-custom.conf

The step applies to an upgrade from VisualSVN Server 4.1 or earlier versions that also have customizations in %VISUALSVN_SERVER%conf\httpd-custom.conf file.

VisualSVN Server 4.2 uses mod_mpm_visualsvn module instead of mod_mpm_winnt, so certain custom configurations result in a misconfiguration error and the VisualSVN HTTP service will not start. You should carefully examine and remove those customizations.

Prior to upgrade consider removing of the following unsupported directives from httpd-custom.conf file:

• ThreadsPerChild
• ThreadLimit

4.1; 4.0; 3.9; 3.8, 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Check if you need to update your VisualSVN Server license

The step applies to an upgrade from VisualSVN Server 3.9 and older version.

Starting with version 4.0, VisualSVN Server can be run under one of the three types of licenses: Community, Essential or Enterprise.

The upgrade to new licensing model is fully transparent if you are using Enterprise Edition of VisualSVN Server and have a license with non-expired maintenance subscription.

If you are using Standard Edition, an upgrade to version 4.1 or later will automatically activate almost functionally equivalent Community license. However, there are two exceptions when the Community license will be not available during the upgrade:

• When there are more than 15 Subversion user accounts. The Community license allows using up to 15 Subversion user accounts.
• When you use Windows (Basic) authentication. Starting from version 4.0, Windows authentication is only available with the Enterprise license.

In case of the above exceptions, you will be offered either to provide a sufficient license, or to generate a free Evaluation license that will allow you to use all VisualSVN Server features for a limit of 45 days. In the latter case, you will be required to provision a sufficient Essential or Enterprise license until the evaluation period ends.

For further details please consider the KB147: How the licensing model changes in VisualSVN Server 4.0 article.

3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Verify that you do not use Internet Explorer 10 to access the VisualSVN Server web interface

The step applies to an upgrade from VisualSVN Server 3.9 and older version.

Starting from VisualSVN Server 4.0, the minimum supported IE version is Internet Explorer 11. You are required to upgrade your web browser if you are still using Internet Explorer 10.

3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Remove customizations related to mod_authz_svn from httpd-custom.conf

The step applies to an upgrade from VisualSVN Server 3.8 and earlier versions that also have customizations in %VISUALSVN_SERVER%conf\httpd-custom.conf file.

VisualSVN Server 3.9 does not include the mod_authz_svn module, so all your custom settings that use directives from this module will stop working. You should carefully examine and remove those customizations. Here is the list of directives you should consider removing from httpd-custom.conf file before upgrading to VisualSVN Server 4.1:

• AuthzForceUsernameCase
• AuthzSVNGroupsFile
• AuthzSVNAccessFile
• AuthzSVNAnonymous
• AuthzSVNAuthoritative
• AuthzSVNNoAuthWhenAnonymousAllowed
• AuthzSVNReposRelativeAccessFile

3.8; 3.7, 3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Plan your upgrade of VisualSVN Server in a multisite environment

The step applies to an upgrade of VisualSVN Server 3.8 and older version in a multisite environment. You should perform this step only if you are using distributed repositories based on VisualSVN Distributed File System (VDFS) technology that are available starting from VisualSVN Server 3.0.

General rule for simple installations is to first upgrade a VisualSVN Server instance where master VDFS repositories are hosted and then upgrade all the corresponding slave instances. Please consider the KB205: Upgrading to VisualSVN Server 5.1 in a multisite environment article if you have a more complex setup when master and slave repositories are mixed on the same instance.

3.8; 3.7; 3.6; 3.5; 3.4; 3.3; 3.2; 3.0

Verify that you do not have customizations that are incompatible with the new version

The step applies to an upgrade of VisualSVN Server if you have any customizations in the httpd-custom.conf file. VisualSVN Server 3.7 brings an upgrade to Apache HTTP Server 2.4 and makes significant changes to the related httpd.conf file. That's why there is a high possibility that your custom settings will be broken after an upgrade.

It is highly recommended to run a test upgrade in a pre-production environment if %VISUALSVN_SERVER%conf\httpd-custom.conf file is not empty in your instance of VisualSVN Server.

3.6; 3.5; 3.4; 3.3; 3.2; 3.0; 2.7; 2.6; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Adjust filesystem permissions if your repositories are stored on a network share

The step applies to an upgrade from VisualSVN Server 1.7 and older version. You should perform this step only if your server is configured to store repositories on a network share. Please skip this step if your repositories are stored locally in the folder such as C:\Repositories\.

Before the VisualSVN Server 2.0, the server was set to run under the built-in Local System account. For better security and isolation, these defaults were changed in the VisualSVN Server 2.0. Your server will be automatically reconfigured to run under the built-in Network Service account if you are upgrading from VisualSVN Server 1.7 or older version. So you are required to grant appropriate network share access permissions to the built-in Network Service account.

For the list of required filesystem permissions, consider the KB22: Storing repositories on a network share article.

1.7; 1.6; 1.5; 1.1; 1.0

Adjust filesystem permissions if VisualSVN Server is installed to a custom location

The step applies to an upgrade from VisualSVN Server 1.7 and older version. Usually, this is an obligatory step if your VisualSVN Server is installed to a non-default location.

As said above, starting from version 2.0 VisualSVN Server runs under the built-in Network Service account. It is required that Network Service account must have read access filesystem permissions to the folder where VisualSVN Server is installed and for all its parent folders. With the default settings, the Network Service account should have read access NTFS permissions to the following folders:

• C:\Program Files (x86)\VisualSVN Server\
• C:\Program Files (x86)\
• C:\

The upgrade process will fail if VisualSVN Server is installed to a non-default location (for example, D:\Applications\VisualSVN Server) or the computer has non-standard security settings configured. In this case you are requested to configure permissions for the above mentioned folders manually. For the further details please consider the KB37: Permissions required to run VisualSVN Server article.

1.7; 1.6; 1.5; 1.1; 1.0

Upgrade without starting VisualSVN Server service if you run it under a custom account

The step applies to an upgrade from VisualSVN Server 1.7 and older version. Perform this step if you run VisualSVN Server under a custom user account. Please skip this step if have not changed default account used to run the server.

To avoid issues during the upgrade process, you must perform installation without starting VisualSVN Server service. Run the installation package using the following command:

The new version will be installed but the service will not start automatically after the upgrade. You are required to manually reconfigure the server to run under the custom account. For further detail please consider the corresponding step in the post-upgrade checklist.

1.7; 1.6; 1.5; 1.1; 1.0

Check the TLS/SSL compatibility level settings (TLS 1.0 and TLS 1.1 are now in Legacy)

Intermediate TLS/SSL compatibility level in VisualSVN Server 5.0 no longer enables the deprecated TLS 1.0 and 1.1 protocols. There are no negative implications for modern clients interacting with the server. However, outdated clients that do not support TLS 1.2 will be getting an access error upon the server upgrade.

Pay attention to the following clients:

• TortoiseSVN version 1.7.8 or older.
• Subversion command line client version 1.8.x or older.
• All clients based on Java 7 or older.

In the event of receiving an access error by the outdated client, consider updating it to a newer version that supports TLS 1.2. If for some reason the immediate update is not an option, switch TLS/SSL settings to the Legacy configuration. Read the article KB195: Understanding TLS/SSL compatibility levels in VisualSVN Server for the detailed instructions.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Enable full-text search for repositories

The step applies to an upgrade from VisualSVN Server 4.3 and older versions.

VisualSVN Server 5.0 provides the new full-text search feature that allows finding files with specified content through the web interface. Read the article KB178: Getting started with full-text search for further instructions.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Enable administrative email notifications

The step applies to an upgrade from VisualSVN Server 4.3 and older versions.

VisualSVN Server 5.0 supports administrative email notifications. These notifications are sent after a background job finishes, notifying the administrator of the job run status. It is recommended to enable administrative email notifications if your server has any background jobs configured. Read the article KB184: Configuring administrative email notifications for further instructions.

4.3; 4.2; 4.1; 4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Check the TLS/SSL compatibility level settings (3DES is now in Legacy)

VisualSVN Server 4.2 Intermediate TLS/SSL configuration no longer uses obsolete 3DES cipher suites. There are no negative implications for modern clients interacting with the server. However, outdated clients that are limited to using 3DES (e.g. Internet Explorer 8 on Windows XP or even earlier) will be getting an access error upon the server upgrade.

In the event of receiving the access error by an outdated client, get it updated to a newer, compatible version (supporting modern AES cipher suites). If for some reason the immediate update is not an option, switch TLS/SSL settings to Legacy configuration. Read the article KB105: Understanding TLS/SSL compatibility levels in VisualSVN Server for the detailed instructions.

4.1; 4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Update custom HTTP and HTTPS firewall rules (service executable is now vsvnhttpsvc.exe)

Starting from version 4.2, the executable file of the VisualSVN HTTP Service has changed its name from “VisualSVNServer.exe” to “vsvnhttpsvc.exe”.

If you have custom firewall rules that reference the VisualSVN HTTP Service by the name of its executable file, such rules need to be updated. Please note that this doesn't apply to the preconfigured “VisualSVN Server (TCP-In)” rule for Windows Firewall that will be updated automatically by the installation package.

4.1; 4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Make sure that your HTTPS certificate allows the use of TLS 1.3

The step applies to an upgrade from VisualSVN Server 4.0 and earlier versions.

You need to double-check whether your certificate allows the use of TLS 1.3.

VisualSVN Server 4.1 adds support for TLS 1.3 protocol on the server side. Normally, TLS 1.3 protocol should become available after the upgrade without any special steps. However, the certificate currently installed may prevent the use of TLS 1.3 protocol. In this case you need to generate and install a new certificate.

Follow these steps to find out whether your certificate supports TLS 1.3 and whether you need to take additional steps:

1. Start the VisualSVN Server Manager console.
2. Click Action | Properties.
3. Click the Certificate tab.
   • If you do not see warnings on the Certificate tab, then the certificate is compliant with TLS 1.3 and additional steps are not required.
   • If you see the following warning, then there is a problem with the certificate that prevents the use of TLS 1.3 on the server:
     This certificate currently prevents the use of TLS 1.3 on the server.
     You need to generate and install a new TLS certificate to resolve the problem. See the article KB134: Configuring SSL Certificates for VisualSVN Server for instructions.

4.0; 3.9; 3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Upgrade repositories to Subversion 1.10 format

The step applies to an upgrade from VisualSVN Server 3.8 and earlier versions.

You need to upgrade your repositories to Subversion 1.10 format in order to benefit from performance improvements implemented in VisualSVN Server 3.9 and Subversion 1.10. Read the article KB142: Upgrading the filesystem format of a repository for instructions.

3.8; 3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Make sure that PowerShell 4.0 or later is installed on the server computer

The step applies to an upgrade from VisualSVN Server 3.7 or older versions.

PowerShell 4.0 or later is required to create and restore encrypted backups or provide custom credentials for remote backup destinations when using the Backup-SvnRepository and Restore-SvnRepository PowerShell cmdlets. We recommend that you make sure that the PowerShell 4.0 or later is installed on the server computer.

PowerShell does not have a standalone installer and it comes only as a part of Windows Management Framework (WMF). You need to upgrade to WMF 4.0 in order to upgrade to PowerShell 4.0. Read the Upgrading existing Windows PowerShell section in the Microsoft Docs.

3.7; 3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Remove the customizations made to dynamic HTTP compression from httpd-custom.conf

The step applies to an upgrade from VisualSVN Server 3.6 and earlier versions that also have customizations in %VISUALSVN_SERVER%conf\httpd-custom.conf file.

VisualSVN Server 3.7 significantly reworks dynamic HTTP compression and provides a user interface to adjust the related settings. In case your server's httpd-custom.conf was modified to customize dynamic HTTP compression settings, these customizations might conflict with the settings in the core httpd.conf configuration file. You should carefully examine and remove those customizations.

Here is the list of directives you should consider removing from httpd-custom.conf file after upgrading to VisualSVN Server 4.1:

• SVNCompressionLevel
• LoadModule mod_deflate

Beginning with VisualSVN Server 3.7, dynamic HTTP compression settings should be adjusted via VisualSVN Server's user interface only.

3.6; 3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Remove the customizations made to TLS/SSL security settings from httpd-custom.conf

The step applies to an upgrade from VisualSVN Server 3.5 and earlier versions that also have customizations in %VISUALSVN_SERVER%conf\httpd-custom.conf file.

VisualSVN Server 3.6 provides a user interface to customize TLS/SSL security compatibility levels. In case your server's httpd-custom.conf was modified to customize TLS/SSL settings, these customizations might conflict with the settings in the core httpd.conf configuration file. You should carefully examine and remove those customizations.

Here is the list of directives you should consider removing from httpd-custom.conf file after upgrading to VisualSVN Server 4.1:

• SSLProtocol
• SSLCipherSuite

Beginning with VisualSVN Server 3.6, TLS/SSL security settings should be adjusted via VisualSVN Server's user interface. For further information please read the article KB105: Understanding TLS/SSL compatibility levels in VisualSVN Server.

3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Remove the customizations made to Subversion memory cache size from httpd-custom.conf

The step applies to an upgrade from VisualSVN Server 3.5 and earlier versions that also have customizations in %VISUALSVN_SERVER%conf\httpd-custom.conf file.

VisualSVN Server 3.6 provides a user interface to customize the size of Subversion memory object cache for server performance tuning. In case your server's httpd-custom.conf was modified to change Subversion memory cache size, these customizations might conflict with the settings in the core httpd.conf configuration file. You should carefully examine and remove those customizations.

Here is the directive you should consider removing from httpd-custom.conf file after upgrading to VisualSVN Server 4.1:

• SVNInMemoryCacheSize

Beginning with VisualSVN Server 3.6, Subversion memory cache size should be adjusted via VisualSVN Server's user interface. For further information please read the article KB114: Understanding VisualSVN Server performance settings.

3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Schedule repository backup

The step applies to an upgrade from VisualSVN Server 3.5 and older versions.

VisualSVN Server 3.6 comes with the built-in Backup and Restore solution for the Subversion repositories. The feature helps you make daily backups of repositories of any size and does not have any impact on performance and user operations. We suggest that you add a scheduled backup job to ensure that your repositories are properly backed up. Read the article KB106: Getting started with Backup and Restore for setup instructions.

3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Schedule repository verification

The step applies to an upgrade from VisualSVN Server 3.5 and older versions.

VisualSVN Server 3.6 comes with built-in scheduled verification of the Subversion repositories. The verification jobs check the integrity of your repositories. Verifying your repositories on a regular basis is important for early detection of repository corruptions caused by disk failures. Read the article KB115: Getting started with repository verification jobs for setup instructions.

3.5; 3.4; 3.2; 3.1; 3.0; 2.7; 2.5; 2.1; 2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Enable Integrated Windows Authentication

The step applies to an upgrade from VisualSVN Server 2.0 and older version. For better security and usability, consider to enable Integrated Windows Authentication that is new feature of VisualSVN Server 2.1.

Please refer to the article KB43: How to configure Integrated Windows Authentication in VisualSVN Server for detailed instruction.

2.0; 1.7; 1.6; 1.5; 1.1; 1.0

Reconfigure VisualSVN Server to run under your custom dedicated account

The step applies to an upgrade from VisualSVN Server 1.7 and older version. If you run VisualSVN Server service under a dedicated custom account and upgraded from version 1.7 or older, you need to reconfigure the service back to the custom account and manually start the service.

After the upgrade, perform the following steps:

1. Reconfigure VisualSVN Server service to run under a custom account.
2. If required, grant this account missing permissions.
3. Start the service manually

For detailed instructions please consider the KB24: Configuring VisualSVN HTTP Service to run under a dedicated user account article.

1.7; 1.6; 1.5; 1.1; 1.0

Reconfigure repository access permissions

The step applies to an upgrade from VisualSVN Server 1.1 and older version. If VisualSVN Server is set to use Windows Authentication, repository access settings will be lost during the upgrade from version older than 1.5. You should reconfigure the desired repository access permissions with the following steps:

1. Start VisualSVN Server Manager.
2. Right-click the Repositories node.
3. Select Properties.
4. On the Security tab specify the desired repository access settings.

1.1; 1.0