Upgrade

Although you can update to the latest version of SVN MultiSite Plus by completing a fresh installation (using the installation guide), you would need to recreate your configuration in terms of node, repository and replication group settings. This upgrade procedure offers a method for upgrading that lets you keep most of your existing configuration.

Follow the procedure that corresponds with your current version:

• Upgrade from SVN MultiSite Plus 1.0 -> Latest


• Upgrade from SVN MultiSite Plus 1.2 Build: 5435 to 5778 (prior to 6903) -> Latest


• Upgrade from SVN MultiSite 1.2 Plus Build: 6903 to later -> Latest

Which version am I running?
The version number of each SVN MultiSite Plus component is tracked. For distinguishing between product releases we use the "svn-ms-replicator" version. You can find it in the following places:

• Listed at the bottom of the admin UI.
• Listed at the bottom of the Settings tab of the admin UI (along with other component versions).
• Without starting up and accessing the admin UI you can see the version in the following file:

  /opt/wandisco/svn-multisite-plus/VERSION

Migration from SVN MultiSite 4.2

If you're upgrading from an earlier version of SVN MultiSite there are some big changes that you need to be aware of.

SVN MultiSite Plus uses a stronger definition of "identical"

SVN MultiSite 4.x (and earlier versions) require that repository replicas be "identical", in that all replica contain identical revisions. SVN MultiSite Plus uses a stronger definition of "identical" in that the repositories must now be byte-for-byte the same (identical in terms of properties, time-stamps, etc).

A migration from SVN MultiSite to SVN MultiSite Plus therefore requires that you ditch all but one copy of each repository. This remaining copy becomes your "master" and must be copied to each applicable node. This ensures that you start from the position where replica are identical.

Migration strategy

Per-repository:

• Repostories are migrated one at a time.
• Less risk
• The preferred approach if installing on existing servers.
• May not be able to preserve the repository URL.

Full migration:

• All repositories are migrated in a single operation.
• "all your eggs in one basket" risk.
• The preferred approach when installing onto new servers.
• Biggest obstical is managing the migration of repository data.

Copying Strategy

In production, repositories can be extremely large, so large that making copies of them can be challenging. There are a number of strategies you can use to manage the distribution of

Strategy 1: Make a physical copy of each repository for real-world trasit. This option makes most sense when the scale of repository data is so great that a WAN network transfer is not practical (e.g. copying Terrabytes of repository data over a low/moderate bandwith connection).

Strategy 2: Full rsync (without checksum). This option is a direct solution that works best if you have the opportunity to copy all repository data during a maintenance window -- you won't be able to continue commiting changes to the original repositories once done.

Strategy 3: Incremental rsync (with checksuming). This option takes a copy of the repository from each location's local server, and then uses an incremental rsync with checksums to make the new copy identical to the master copy. The best way to accomplish this is to mount the storage of the MultiSite 4.2 node in read-only mode on the MultiSite Plus service, then copy the data to the real location on the MultiSiet Plus node.

Periodic incremental synchronization of the repository

This approach updates MultiSite Plus copied of the repository with the commits made since the last rysnc Note that the following steps will update the MSP copies of the repositories with the commits since the last rsync, but these repositories will not be guaranteed correct. Section 5 explains how to finalise the repository synchronization before it can be replicated by MSP.

Finalize the copy

In order to guarantee a correct repository, a final incremental rsync needs to be run after the repository has been made read-only.