tags:

views:

1676

answers:

6

Hi there.

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!

+11  A: 

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 carefu

crashmstr
+3  A: 

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.

Paul de Vrieze
I completely agree.
Jason Jackson
The only time you would see a protocol speed effect would be when updating, checking out or exporting a svn tree.
Redbeard 0x0A
Oh, and when doing a commit (how do I forget the most important function of SVN??)
Redbeard 0x0A
And merging, which is also pretty important
zcrar70
+1  A: 

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.

BrianLy
+1  A: 

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.

Peter Parker
A: 

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.

Mike Miller
A: 

Thanks for the responses everyone! After some performance testing, I've found that the file:// protocol is marginally faster than http:// - but may not be fast enough to outweigh other administrative issues that should be taken into consideration.

I was comparing those 2 protocols initially because I was using VisualSVN server, which doesn't support the svn:// protocol. After reading (Rick Strahl's article), I found that svnserve.exe could be loaded as a windows service, which could support the svn:// protocol, but I don't think that configuration is supported by VisualSVN. If anyone wants to set that up for themselves, the command to load as a windows service is:

sc create svn binpath= "\"c:\program files\subversion\bin\svnserve.exe\" --service -rd:\subversion" displayname= "Subversion Server" depend=Tcpip start= auto

mallio