This guide runs through everything you need to know to get SVN MultSite Plus deployed. First we'll cover all the things that you need to have in place before you install. We'll then cover a standard installation and setup. Finally we'll look at some possible problems you might experience with some troubleshooting tips.

1. Before you deploy

Before installing SVN MultiSite Plus we need to ensure that we have sufficient hardware and all required software configured appropriately.

1.1 Skills requirement

This section details the knowledge and technical requirements for deployment and operation of SVN MultiSite Plus. You should ensure that each of these requirements is satisfied before you begin the deployment.

Technical Skill Requirements

 System administration
  • Unix operating system installation
  • Disk management
  • Memory monitoring and management
  • Command line administration and manually editing configuration files
  • Service (init.d) configuration and management

 Apache administration (if applicable)
  • Familiarity with Apache web server architecture
  • Management of httpd.conf / Apache2 configuration file management settings
  • WebDAV protocol
  • User authentication options
  • Log setup and viewing

  • IP Address assignation
  • TCP/IP ports and Firewall setup

 SVN and MultiSite Plus

If you're not confident about handling any of these tasks, you can request a supported installation from WANdisco.

A single administrator can manage all the systems running MultiSite Plus, although it's a good idea to have someone at each site who is familiar with the MultiSite Plus Basics.

1.2 Deployment overview

As with any software implementation you should deploy SVN MultiSite Plus following a well defined plan. We recommend that any deployment plan includes the following steps:

1.3 System requirements

This section covers everything you need to know if you are preparing existing servers for replication. You should view this information as a set of guidelines, not as a fixed set of requirements. There are a lot of factors at play and there's really no substitute to running your own performance tests during an evaluation period.

Hardware Recommendations

Hardware Sizing Guidelines
Size #Users Repository Size (Gigabytes) CPU speed (Gigahertz) #CPU #Cores RAM (Gigabytes) HDD (Gigabytes)
Small 100 25 2 1 2-4 8-16 100
Medium 500 100 2 2 4 16-32 250
Large 1000 500 2.66 4 4 32-64 750
Very Large 5000 1000 2.66 4 4-6 128 1500

tip GB or GiB
We should clarify how we refer to measures of memory and data. SVN MultiSite Plus has now adopted the binary prefixes as provided by the International Electrotechnical Commission. We therefore use Mebibyte (1024 bytes) instead of Megabytes (1000 bytes) within our products. However, we'll still refer to Megabytes and Gigabytes where these are more commonly understood - such as in the above table.

If you're not familiar with the difference between the binary prefixs and the SI prefixes then we recommend that you give the following Wikipedia article a read -

Storage tips

Running in virtualization

Processor tips

Setup requirements

MultiSite Plus Servers must have:

This is a summary of the requirements, you'll need to run through the more detailed Installation Checklist.

SVN installations:

We recommend that you install SVN during the installation of SVN MultiSite Plus. You can choose between version 1.7 or 1.8, both have the necessary WANdisco-modified FSFS libraries already included. Regardless of the version of SVN that you use, it must include:

tip Requirement
If you run an existing installation of SVN instead of installing it during the setup of SVN MultiSite Plus, you need to make sure that it contains WANdisco's modified FSFS libraries.

You must run SVN and SVN MultiSite Plus on the same server.

** Alert! **Alert
A repository can belong to only one replication group at a time.

2. Installation Checklist

Though you may have referred to the Installation Checklist prior to an evaluation of SVN MultiSite Plus we strongly recommend that you revisit the checklist and confirm that your system still meets all requirements.

 System setup

 Operating Systems

We've tested the following operating systems:
  • Red Hat Linux Enterprise Server (32 or 64 bit): versions 5.x and 6.x

    High Level of confidence
    We've limited our testing to RHEL/CentOS so that we can provided a high level of confidence about operability, which would not be possible if we spread our testing across a larger number of distributions.

    Maximum confidence
    If you want the highest possible level of confidence you should match the version of RHEL used on your nodes with one of those that we use in our testing. These currently include 5.9, 6.1, 6.2, 6.3, 6.4 and 6.5.
    tip Running with 32-bit RHEL
    In order to run with 32-bit Red Hat (though 32-bit architecture is not recommended for production), you will need to edit multisite-plus/config/main.conf and change the maximum Java heap listed in the MSP_REP_MEM_HIGH parameter to be 2.5 Gigabytes or less otherwise the replicator will not start.
  • CentOS: versions 5.x and 6.x

  • Debian: versions 6.x and 7.x

  • SUSE Linux Enterprise: version 11.

  • tip Go 64-bit
    While it's possible to run SVN MultiSite Plus on 32-bit architecture, this would impose serious limits on scalability. For this reason we strongly discourage deploying on anything less than a 64-bit Operating System unless your requirements are limited to a handful of sites and less than a hundred repositories.

 SVN Server

Recommended Version:
Installing the version of SVN that is bundled with SVN MultiSite Plus is the best option as this takes care of the requirement for running with WANdisco's customized FSFSWD libraries, it is also offers the benefit of being a version of SVN that have been extensively tested with MultiSite.

Repository Creation:
If you are running with repositories that use the old Berkeley DB, make sure that all the repositories you intend to replicate are created or recreated as follows:
	svnadmin create Repo --fs-type fsfswd
	Then edit Repository_name/db/fsfs.conf (view an example fsfs.conf file)

	uncomment the line:
	#rep_port = 7777
Write access for system user
The replicator user must have write permission for all repositories - as the replicator writes directly to the SVN repository.

Manage repository file ownership if using SVN+SSH:// or file://
Accessing SVN repositories via Apache2+WEBDAV is simplified by the fact that all user access is handled via the same daemon user. SVN+SSH or file:// access is a little more tricky, there are potential permission problems when multiple users access the same repository.

  • Simplify user management by putting SSH users into a single group, you can then ensure that the group has read-write permissions for the repositories.
  • Make repositories wholly owned by the group.
  • Ensure that the prevailing umask is set to provide suitable permissions (002 instead of the default 022).
  • Use wrapper scripts for commands such as svn, svnadmin , svnserve etc. Note that with svn+ssh , an svnserve instance running as the user is spawned, so the wrapper will get called there too).

tipCertified SVN Binaries
are now available from WANdisco. Providing the latest builds, without the risks associated with Open Source distribution.

** Alert! **Same location
All replicas must be in the same location (same absolute path) and in exactly the same state before replication can start.

** Alert! **Same UUID
If you start with new repositories, don't create them individually at each site. This is because even though they may share the same repository data, each will have its own universally unique identifier (UUID) - unless the repositories have the same UUID they're not replicas. For more help, read the section about Setting up Repositories for Replication.
Conversely, two different repositories must not share the same UUID - See UUID Warning.

** Alert! **svnadmin pack support
It's not currently possible to run the svnadmin pack command when running SVN MultiSite Plus. Support for this command is currently being added to FSFSWD and should be available in the near future.

Linux Standard Base

LSB provides developers with a degree of confidence about their applications being able to run on a range of distributions. The package is widely included by default, but not always.

Run the following command to verify the version of LSB yours server is running:

[root@redhat6 wandisco]# lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.4 (Santiago)
Release:        6.4
Codename:       Santiago

SVN MultiSite Plus's init.d scripts are dependent the the LSB package. Running the installer script, if the package isn't present it should be downloaded before the installation continues.

 SVN client

Any that are compatible with local SVN servers.

  • Hook scripts no longer need to be replicated on all repository replicas - See details

 System memory

Minimum recommended: 8 Gigabytes RAM; 16 Gigabytes swapping container

** Alert! **Memory requirements of DConE2 replication
Each state machine, or replicated object (repository/replication groupe, etc) needs about 1MB of system memory to run. So for small to moderate deployments the memory requirement of the replication system itself is quite modest. For very larger deployments where you are replicating hundreds or more repositories then you may need to consider the specific memory requirements of the DConE2 replication engine.

 Disk space

SVN: Match to projects and repositories.
MultiSite Plus Transaction Journal: Equivalent of seven days of changes.

Estimating your disk requirements can be very difficult and there's no perfect system for making an accurate estimation. Some organizations monitor their repository growth over a period of time and use an extraopolation as a guide. This method works best if your organization is unlikely to see the addition of large new projects that instantly introduce large amounts of extra repository data.
you need to quantify some elements of your deployment:
  • overall size of all of your SVN repositories.
  • frequency of commits in your environment.
  • types of files being modified - text,binaries (SVN clients only send deltas for text).
  • number and size of files being changed.
  • rate that new files are being added to the repository.

** Alert! **Talk to those who know
There is absolutely nothing like having a solid communications path between those managing the SVN system resources and those who manage the development project. Actually talking to the people who are planning upcoming SCM efforts is better than trusting an abstract system for measuring requirements.

 Maximum User Processes and Open Files limits

Maximum User Processes and Open Files limits are low by default on some systems. It is possible to check their value with the ulimit or limit command:
ulimit -u && ulimit -n 

-u The maximum number of processes available to a single user.
-n The maximum number of open file descriptors.

For optimal performance, we recommend both hard and soft limits values to be set to 64000 or more:

RHEL6 and later: 
A file /etc/security/limits.d/90-nproc.conf explicitly overrides the settings in security.conf, i.e.:
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 1024 <- Increase this limit or ulimit -u will be reset to 1024  

 Journaling file system

Replicator logs should be on a journaling file system, for example, ext3 on Linux or VXFS from Veritas.

    ** Alert! **Alert
    NFS must not be used with SVN MultiSite Plus- Why you shouldn't use NFS.

    ext4 can be used as your journaling file system, although it must be configured appropriately. See Using Ext4 filesystem for journaling .

    tipAvoiding Data Loss.
    We have an article in our Knowledge Base that looks at a number of implementation strategies that will militate against potential data loss as a result of power outages - Data Loss and Linux.


Install JRE or JDK 7

** Alert! **Use Oracle Java
Our development and testing is done using Oracle JDK 7 and JDK 6. While it may be possible to use other Java packages, we will not be able to support you unless you run with Oracle's package.

  • 1. Install JDK/JRE 7 (from Oracle) and define the JAVA_HOME environment variable to point to the directory where the JDK/JRE is installed.
  • 2. Add $JAVA_HOME/bin to the path and ensure that no other java (JDK or JRE) is on the path.
    $ which java
    $export JAVA_HOME="/usr"
    $export JAVA_HOME="/export/share/apps/jdk/1.6.0"
  • It is possible to run with the JRE package instead of the full JDK. You can check this by running java -server -version. If it generates a not found error, repeat Steps 1 and 2.
    If you find package management problems or conflicts with the JDK version you are downloading (for example, rpm download for Linux), you may want to use the self-extracting download file instead of the rpm (on Linux) package. The self-extracting download easily installs in any directory without any dependency checks.


Install version 2.3 or later.

 Browser Compatibility

Set up and configuration requires access through a browser, what follows is a basic (not exhaustive) guide to which browsers are known to work:
  • Internet Explorer 10
  • Firefox 24
  • Google Chrome 30
  • Safari 7
  • Some earlier browser versions may work. However, we will not have completed thorough testing with older versions, we recommend that you keep browsers up-to-date.

** Alert! **SVN MultiSite Plus is not compatible with either Internet Explorer 6 or 7
While we understand that some users are still tied to earlier versions of Internet Explorer, those earlier versions do not support modern web technologies and we are unable to support them.

 Kerberos SSO

We support the implementation of Kerberos for single sign-on. By default Kerberos requires that stronger encryption algorithms be available than are currently provided by default in Java 6/Java 7. This is so that Oracle can avoid the complications that arise from countries that place import restrictions on encryption technology.

The stronger encryption algorithms are available as an optional download where the user takes responsibility for compliance with the local laws.
For Java 6: JCE Unlimited Strength Jurisdiction Policy
For Java 7: JCE Unlimited Strength Jurisdiction Policy

Once downloaded, extract the contents to (and overwrite the existing contents of) the Java security library directory on all nodes.
 Network settings

 Reserved ports

There are a number of ports that will be reserved by MultiSite Plus. It's possible to change these ports after completing the installation - 6. Update a node's properties. The default values suggested during the installation are the following:

Required Ports

dcone.port= An integer between 1 - 65535 (Default: 6444)
DConE port handles agreement traffic between sites

content.server.port= An integer between 1 - 65535 (Default: 4321)
The content server port is used for the replicator's payload data: repository changes etc.

delegate.port= An integer between 1 - 65535 (Default: 7777)
The delegate port is used by SVN to delegate write operations to the WANdisco Replicator (via the above content.server.port)

jetty.http.port= An integer between 1 - 65535 (Default: 8082)
The jetty port is used for the MultiSite Plus management interface.

jetty.https.port An integer between 1 - 65535 (Default: 8445)
The jetty port is used for the MultiSite Plus management interface when SSL encryption is enabled.

** Alert! **Make each port different
In contrast with earlier versions of SVN MultiSite Plus which used the same port for both the UI and replication traffic, SVN MultiSite Plus doesn't multiplex different traffic on a single port. You will need to assign a different port to each type of traffic.

 Firewall or AV software

If you have a virus scanner running on the system housing your repositories and replicator you should:
  • Ensure that you make frequent backups of your repository data
  • If possible, configure your AV system to "Notify Only". Otherwise you should prepare for the possibility that a virus infection or for that matter a false-positive could result in potentially catastrophic corruption of either repository or system data.
Whilst it's true that virus scanners don't normally work via port filtering, some AV In general, virus scanners don't filter ports: firewalls do that. However, some "Anti-Virus" products contain firewall-like filtering capabilities - if this is the case in your platform, you should make sure that you understand what impact it could have on your MultiSite deployment.

Set up IPsec tunnel, and ensure WAN connectivity.

 VPN persistent connections

Ensure that your VPN doesn't reset persistent connections for SVN MultiSite Plus.


Put your WAN through realistic load testing before going into production. You can then identify and fix potential problems before they impact productivity.

 DNS setup

Use IP addresses instead of DNS hostnames, this ensures that DNS problems won't hinder performance. If you are required to use hostnames, test your DNS servers performance and availability prior to going into production. It's possible to change these details after completing the installation - 6. Update a node's properties.


SVN MultiSite Plus provides a limited system for monitoring system disk space available. This monitor is intended only to provide a deployment with a last line of defence against running out of storage space. We recommend that you deploy a system-wide monitor that ensures that you quickly identify potential problems that could impact services.

tipMonitor Recommendation
Read our recommendations for system-wide monitoring tools

 Load Balancing

The use of a correctly configured load balancer can greatly benefit performance in situations where there could be large numbers of concurrent SVN users. However, SVN MultiSite Plus requires that any load balancing solution has the following features:

  • Stateless session persistence.
    Any potential SVN load-balancer needs the ability to handle stateless session persistence within its load balancing algorithm. This is because each Subversion commit needs to go to the same backend node in its entirety or the commit will fail. We achieve this by ensuring the client is bound to a particular back-end node in some way.
    • Client's IP Address - Not always an option, but this IP-based persistence is easy to manage when the network is stable with static IPs.
    • Cookie-based persistence - SVN command line clients can't read cookies so for a load balancer to use cookies for the binding they would need to be able to use sticky cookies that are not reliant on the client honoring them.

  • Node health-checking
    Another vital requirement is the support for a health check mechanism - whereby the load-balancer makes periodic checks on the connected nodes to make sure that it isn't passing traffic to an off-line or overloaded server. Any prospective load-balancer should support HTTP status code (application-layer) checks.
  • The load-balancer sends HTTP GET or HEAD requests to back-end nodes. Watching for 'unhealthy' response codes offers greater reliability and flexibilty than doing your checks belofe the network layer.

 MultiSite Plus setup

 Replication Configuration

Read our Replication Setup Guide for information on how to optimise your replication - Replication Setup.

 Voters follow the sun

To ensure best performance, make sure that SVN MultiSite Plus can deliver the content of a commit to another local node. SVN MultiSite Plus normally requires that content reach at least one other node for data integrity purposes. As the content normally represents the bulk of the data in a commit, having a second local node available will improve performance. Furthermore, you may wish to use our scheduling system to modify the voter roles so a proposal may be accepted by local voter nodes during regular working hours. If you need more help with setting up the most efficient deployment please get in touch with our support team.

 Disk space for recovery journal

Provision enough disk space for /opt/wandisco/multisite-plus/replicator/database to cover the expected number of commits for four hours of peak usage.

 License Model

SVN MultiSite Plus is supplied through a licensing model based on the number of nodes and users. WANdisco generates a license file matched to your agreed usage model.

Evaluation License

To simplify the process of pre-deployment testing SVN MultiSite Plus is supplied with an evaluation license. This type of license imposes no restrictions on use but is time-limited to an agreed period.

Production License

Customers entering production need a production license file for each node. These license files are tied to the node's IP address. In the event that a node needs to be moved to a new server with a different IP address customers should contact WANdisco's support team and request that a new license be generated. Production licenses can be set to expire or they can be perpetual.

Special Node Types

SVN MultiSite Plus offers additional node types to provide limited sets of functionality:

Passive Nodes (Learner only) - A passive node operates like a slave in a master-slave model of distribution. Changes to its repository replicas only occur through inbound proposals, it never generates any proposals itself.

Voter-only nodes (Acceptor only) - A voter-only node does not contain repositories. It casts votes based only on the basis of replication history without knowing the actual contents of the proposal data.

These limited-function nodes are licensed differently from active nodes. In short the IP addresses will be a fixed list but the node count and special node count may move between sets of nodes, as long as the number of each type of node is within the limit specified in the license. Speak to WANdisco's sales team for more details.

2.1 Migrating from WANdisco's SVN MultiSite 4.x

SVN MultiSite Plus uses a new version of WANdisco's DConE replication engine and has a different architecture compared with earlier versions of MultiSite. As a result there are some special considerations when migrating from SVN MultiSite 4.x

Byte-for-byte replicas

Repository replicas must be byte-for-byte mirrors of each other. This stringent requirement did not apply to SVN MultiSite 4.x - the previous tests for whether replicas are identical are not sufficient for FSFSWD replication (see 4.2 vs Plus, below). As a result you will need to recreate your replica repositories using a nominated master repository.

The exact process of copying repositories may need to be carefully thought out in order to be practical and achievable. Many production repositories will take a long time to checksum. If you are in any doubt about handling the process, talk to your WANdisco account manager.

tip4.2 vs Plus
SVN MultiSite 4.2 replication is done using a proxy that sits between SVN and clients that replays commit operations from the users on the repository via Apache and so constructs a new transaction at every node. In contrast, SVN MultiSite Plus applies the same FSFS db/transactions at each node. This transaction is constructed based on the contents of the rev files - so with FSFSWD the repositories need to be identical at the revision (and revprop) file level.

Authentication /Apache

SVN MultiSite Plus opens up more options because MultiSite is no longer running as proxy and options that were previously not compatible with MultiSite now are compatible.

Other factors to consider

3. Installation

The installation guide runs through setting up SVN MultiSite Plus for the first time. If you are upgrading from an earlier version of SVN MultiSite Plus you should also follow this procedure - SVN MultiSite Plus is a completely new class of product so it's not possible to follow a shortcut upgrade procedure.

3.1 Installation overview

Before we begin, here is a recap of the installation process:

3.2 Before you start

Some things you should bear in mind before starting the installation:

3.3 Starting the installation

This procedure requires the entry of various settings into the terminal session during the installation. You can run the installation in a non-interactive mode which doesn't require user input (until then post-installation browser-based set up). To use the Non-interactive mode, see Non-interactive Installation

tip Run SVN MultiSite Plus installer as root
The installation will require full system access so you must run the installer as root or a user with equivalent permissions.

Non-interactive Installation

It's now possible to install SVN MultiSite Plus non-interactively. To do so the following environment variables must be set:

The system user that run MultiSite Plus.
The system group that MultiSite Plus will run within.
The TCP port the browser UI will initially use - you'll be able to change this during the browser-based setup.
Should you wish to exclude the SVN installation that is incorporated into the SVN MultiSite Plus installer you should use this variable. Note that if the server doesn't already have a compatible version of SVN installed, the SVN MultiSite Plus installation will not complete.

Optional variables:
The minimum amount of UI memory.
The maximum amount of UI memory.
The minimum amount of Replicator memory.
The maximum amount of Replicator memory.

A scripted start to the installation requires the running of the following command:

The installation will then run without user interaction. Once installation is completed, the browser-based UI will start. You'll then need to complete the node set up from step 10.

4. Repeat the installation process at all sites

Now repeat section 3 for each node that you wish to share your SVN repositories - note that we will take the configuration files from the first node and use them during the installation of all additional nodes to ensure that all nodes are started with the same administrator account - a requirement for a successful induction.

You may benefit from creating an image of your initial server, with the repositories in place and using this as a starting point on your other sites - this will help you ensure that your replicas are in exactly the same state.

** Alert! **Same Location
All replicas must be in the same location (same absolute path) and in exactly the same state before replication can start.

** Alert! **Same UUID
If you start with new repositories, don't create them individually at each node. This is because even though they may share the same repository data, each will have it's own universally unique identifier (UUID) - unless they have the same UUID they're not replicas.

Ensure that all nodes have matching configuration before completing the inductions

5. Node Induction

After installing SVN MultiSite Plus at all sites, you'll need to make the sites aware of each other through the node induction process. There's a particular way that you need to run through this process so get another coffee and don't skip this section.


It's important that sites are connected together in a specific sequence. Run through the following steps to ensure that your sites are all able to talk to each other:

If Induction fails

If the induction process fails for whatever reason you may be left with the inductee in a pending state.

  1. From the Nodes tab, review the state of your prospective node. During the induction process a prospect will display a Connectivity Status of "Pending Induction". The process should complete within a few seconds, providing that there isn't a network connection problem.

    If the prospect appears to be stuck in the pending state then click the Cancel Induction link.
    ** Stuck **

  2. A growl message will confirm that the induction was cancelled successfully. Click the Reload button to clear the cancelled induction.

    ** Stuck **
  3. Repeat the induction procedure after confirming:

    • You are entering the correct details for the inductee node.
    • There isn't a network outage between nodes.
    • There isn't a network configuration problem, such as a firewall blocking the necessary ports.
    • There isn't an admin account mismatch between nodes - this occurs if you don't use the correct procedure for installing a second or subsequent node If the admin account doesn't match because nodes were not installed using the first node's file then you should follow Matching a node's admin settings.
    • There isn't a product license problem. Should the license file clash between two nodes, or be missing from a node this could cause induction to fail. License problems are noted in the Application Logs.

Matching a node's admin settings

We ensure that all nodes start with a common admin account by importing the admin settings from the first installed node during the installation of all subsequent nodes. In the event that a node is accidently installed without this match you can use the following procedure to resync them. You'll need to follow this if you wish to induct the mismatched node into a replication network that includes the other nodes.

  1. Log in to your first node, click on the Security and click Export Security Settings to perform a security (user) settings export.
    ** export settings **
  2. Access the same node using a terminal window. Copy the exported settings file (/opt/wandisco/svn-multisite-plus/replicator/export/security-export.xml) to a location on the node that you fixing. e.g.
  3. Log in to the admin UI of the node that you're fixing. Click on the Security tab then click the Import Secure Settings button.
    ** export settings **
  4. Enter the path to the copied across security-export.xml file then click Check. You'll be presented with a Diff report that shows you what differences exist between the current user settings and those in the exported file. ** export settings ** Click Import to overwrite the existing admin user settings with the correct user settings that will match those used in the other nodes.

  5. Now that the admin user account details are matching again you'll be able to complete an induction of the corrected node into a replication network.

6. Create a Replication Group

SVN MultiSite Plus lets you share specific repositories between selected sites. This is done by creating Replication Groups that contain a list of sites and the specific repositories they will share.

Create Replication Groups

This illustration shows a collection of four sites that are running two replication groups. Replication Group one replicates Repo1 across all four sites, whilst Replication Group 2 replicates repo2 across a subset of sites.

Follow this procedure to create a Replication Group. You can create as many replication groups as you like. However, each repository can only be part of one active replication group at a time.

7. Add Repositories

Once you have added at least one Replication Group you will be able to add repositories to your node. Here's how:

tip Warning
A repository UUID is integral to the way SVN Multisite Plus tracks repositories. You must not introduce repositories that have duplicate UUIDs.
This means:
  • You cannot add two existing repositories with the same UUID.
  • You cannot use "svnadmin load --force-uuid" if the load will use a UUID that already exists on an SVN MultiSite Plus replicated repository.
  • You cannot use "svnadmin setuuid" on a repository, and use a UUID that already exists on an SVN MultiSite Plus replicated repository.