Upgrading to VisualSVN Server 4.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.

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.

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

• 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 KB150: Upgrading to VisualSVN Server 4.0 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

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

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

Starting from VisualSVN Server 3.7, the minimum supported operating systems are Windows Server 2008 R2 and Windows 7. You are required to move your server to a newer operating system if your current OS is not supported anymore.

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<

Estimate the time potentially required for manual reconfiguration of repository access permissions

The step applies to an upgrade from VisualSVN Server 2.5 and older version. But this step is not applied if you have Windows Authentication enabled in your server.

VisualSVN Server 4.0 installer automatically migrates repository access permissions to a new format. It’s not always possible to perform this migration unambiguously and manual reconfiguration may be required. For further details regarding the migration of repository access permissions, consider the KB63: Reconfiguring access permissions after upgrade to VisualSVN Server 2.7 article.

We recommend to examine existing repository access permissions and estimate the time that may be required for manual permissions reconfiguration after the upgrade. Please check the conditions listed below.

Manual reconfiguration of repository access permissions may be required after the upgrade if all of the following conditions are met:

• You have Subversion Authentication enabled in your server.
• There are access rules configured on the Repositories node.
• There are access rules configured on the root of any of your repositories.

Repository access permissions settings will be migrated automatically and unambiguously if at least one of the above conditions is not satisfied.

The time required for manual reconfiguration of repository access permissions depends on the number of repositories and on the complexity of configured access rules. For further details regarding the manual permissions reconfiguration, consider the KB63: Reconfiguring access permissions after upgrade to VisualSVN Server 2.7 article.

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

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

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

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

• 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

Examine the upgrade report and reconfigure repository access permissions if required

The step applies to an upgrade from VisualSVN Server 2.5 and older version. VisualSVN Server 3.9 installer generates a detailed report that helps you to determine which repository access rules have been migrated successfully and which ones require your attention. The report is saved to %LOCALAPPDATA%\VisualSVN Server\Install\. You have to examine the report and reconfigure repository access permissions accordingly.

Please refer to the article KB63: Reconfiguring access permissions after upgrade to VisualSVN Server 2.7 for detailed instruction.

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

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