Upgrading to VisualSVN Server 3.6

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.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.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 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.6 brings significant changes to the related httpd.conf file and there is a very high possibility that all 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.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 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 firstly upgrade a VisualSVN Server instance where master VDFS repositories are hosted and then upgrade all the corresponding slave instances. Please consider the KB104: Upgrading to VisualSVN Server 3.6 in a multisite environment article if you have a more complex setup when master and slave repositories are mixed on the same instance.

3.4; 3.3; 3.2; 3.0

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

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

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

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

Remove 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 3.6:

• 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 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 3.6:

• 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

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

Upgrade format of repositories

The step applies to an upgrade from VisualSVN Server 1.1 and older version. To be able to use new Subversion functionality such as merge tracking, you are requested to upgrade repositories format with the following steps:

1. Start VisualSVN Server Manager.
2. Right-click the Repositories node.
3. Select All Tasks | Upgrade Repositories Format.
4. Select the repositories to upgrade and click OK.

1.1; 1.0