6
votes

I'm just getting started/familar with Subversion and was wondering which protocol gives the best performance file:// or svn://, when accessing a Subversion repository over the network? If we don't use the svn:// protocol, will be missing out on any features that we couldn't mitgate using the file:// protocol? We're all on the same NT domain & plan on using Windows Auth and use NTFS/UNC security.

TIA!

5

5 Answers

14
votes

The SVN Book recommends that you do not use the file:// protocol for multiple users

Choosing a Server Configuration:

Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful

7
votes

If you want to use windows auth, use the http(s) protocol, together with apache. It is a bit harder to set up, and not necessarily faster, but allows you to use standard apache authentication methods for authentication. Including various windows based authentication schemes, or kerberos.

Btw. Normally protocol speed is not a factor with svn speed. Svn caches the info on disk, so most regular actions are based on local cache. Next, the speed factor is in the repository and the network bandwith, not in the protocol.

5
votes

A checkout/update over svn:// is approx 4-12 times faster than over http(s):// . The factor depends on number of files/folders and file size . Apache is much slower on many small files because each file is a full http-request-response cycle. In Tortoise you can easily see the speed dropping:

Checkout a large java projects If you transfer a huge .jar, transfer is going up, on getting source java files and creating package structure, it will drop.

Also important is that svn checkout is slower on client than svn export and also eclipse(java) is much slower than tortoise/CMD.

1
votes

I agree with the others that svn:// is far far faster then http://. That being said, I use http:// on my repositories because I like mod_authz_svn's access control file and I have not yet upgraded to 1.5.

Since my main repository is huge, we maintain the svn:// running as read only. What I suggest to users is to make your initial checkout as svn:// then use svn relocate to turn it to the http:// url to commit. Updates on svn:// run in acceptable time for us.

0
votes

As Paul de Vrieze states the protocol used by SVN is not going to impact performance as much as other factors. If you are on a small local area network then the SVN protocol may be satisfactory for you. In all other cases it seems to be best to use HTTPs:// with Apache. I've been on LANs where the performance of SVN:// is worse than HTTPS:// connections to the internet.

You will also find the Apache is probably a more manageable solution too in terms of security, or SVN repository viewing.