Subversion Hardware Considerations

General Observations

1. Subversion transactions are handled in their own thread and a multi-core CPU is recommended

2. Subversion operations tend to be disk access and memory limited

3. Use the svn://protocol when connecting a client to a Subversion repository

In SVN the metadata for each file in the users local workspace is kept in the .svn directories of each subdir, and Subversion must traverse all of these subdirs gathering change information as part of each command. For a large working copy with slow disk access this can lead to "churning". For this reason we recommend a well spec'd server with fast disk IO to host the Subversion repos.

4. We recommend users keep their local workspaces on a local disk to their desktop machines, and that these local disks have a fast access time. 90% of performance issues can be attributed to this activity in the local workspace.

5. XFS on Linux tends to be the preferred OS and filesystem combination

http://linuxgazette.net/122/TWDT.html#piszcz

http://kb.perforce.com/article/779/file-system-comparison

6. Avoid using a Virtual Machine for your server

http://kb.perforce.com/article/5/recommended-server-hardware-configurations

7. RAID10 is preferred

8. At Perforce we've started using Intel X-25 160GB SSD drives to great effect.

Example Server Spec

Here's a server we spec'd (and helped build) for a recent customer:

Qty:        1
Product:    HP ProLiant DL380 G7 Performance - Xeon X5660 2.8 GHz
Qty:        6
Product:    EDGE memory - 4 GB - DIMM 240-pin - DDR3
Qty:        8
Product:    HP Dual Port Enterprise - hard drive - 600 GB - SAS (10k)
Qty:        4
Product:    HP Dual Port Enterprise - hard drive - 146 GB - SAS (15k)

ProjectIC BOM Methodology

Note that with the BuildIC Bill of Materials (BOM) methodology you can leverage multiple servers if you choose. Each IP block is fully defined in the BOM and servers can be located along geographical or project lines as desired.

for example, the following BOM fragment includes blocks from various servers on the network

[3G_ADC]
dm_type = Subversion
host = 192.168.1.43:49494
label = rev_1.1
trunk = //depot/radio/3G_RADIO/trunk/3G_ADC
branches = //depot/radio/3G_RADIO/branches/<ip_release>/<ip_name>[3G_DSP]
dm_type = Subversion
host = 192.168.1.68:49494
label = rev_1.2
trunk = //depot/radio/3G_RADIO/trunk/3G_DSP
branches = //depot/radio/3G_RADIO/branches/<ip_release>/<ip_name>[3G_LNA]
dm_type = Subversion
host = 192.168.1.91:49494
label = rev_2.1
trunk = //depot/radio/3G_RADIO/trunk/3G_LNA
branches = //depot/radio/3G_RADIO/branches/<ip_release>/<ip_name>

So with Perforce, you control whether your DM architecture uses a single server or multiple ones across geographical boundaries. The BOM allows for any user workspace configuration and remote-site replication.