Which protocol? svn:// or http(s)://?

问题:

There are four common protocols for network access of SVN.

svn://repos
svn+ssh://repos
https://repos
http://repos

The Wikipedia page doesn't say much about the differences of the four different protocols. I've always preferred svn://, because it is the easiest to set up, but what is the difference and which one is "better"?

回答1:

http:// has a serious overhead, especially when dealing with thousands of small files. I used svn for a website that had around 50,000 icons, all saved in SVN. With HTTP, it took around 20 minutes to checkout. Once I switched to svn://, it took less than a minute. This is because with HTTP it's one new HTTP request per file.

http:// however has the following big advantage: it usually goes through firewalls. For example, now that I switched to svn:// I can no longer access my repository from my university because of their firewall.

Regarding the difference between using SSL/TLS or not, well, it's obvious: data is encrypted; however it's more difficult to set up.

回答2:

svn+ssh is the svn protocol run inside a SSH tunnel. The client uses SSH to log on the remote server and remotely runs the svn command in that tunnel. In my view, svn+ssh is the easiest way to use a subversion repository on a distant system, because you do not have any server to launch on that system, assuming that you already have a SSH server running.

Also, svn+ssh benefits from the cryptographic protection of SSH. Do not use raw svn protocol over untrusted networks.

The main problem with svn+ssh is that it requires shell access on the remote machine. It is difficult to offer someone access to the repository without giving him access to the whole shell account. For that, you want one of the HTTP-based methods, i.e. http or https (preferably https because of the encryption-and-authentication layer). These methods are more complex to configure (you need a HTTP/HTTPS server, e.g. Apache) but allow the repository administrator to carefully and precisely control repository access rights.

回答3:

https:// and svn+ssh:// are encrypted and so are safer for transmitting secure data (such as your SVN password.

If it's anything like Git, svn+ssh:// will be faster than https:// and svn:// will be faster than http://.

回答4:

Also if you use http:// (Apache + SVN) then you can get your users to log in using Windows Authentication with the addition of the mod_auth_sspi module.

See here: http://blog.pengoworks.com/index.cfm/2007/11/1/Configuring-Windows-Authentication-with-Apache-22x-and-Subversion

So your (windows) devs only have to remember one user / password

回答5:

http and https are handled by web server module for Subversion support, so you can use HTTP-based authentication (configured through .htaccess) to limit access to your repository).

回答6:

One might say that svn:// or svn+ssh:// provide far better performance and speed than plain HTTP or secure HTTPS when accessing Subversion repositories, but this is not true nowadays. While svn:// or svn+ssh:// are faster than HTTP(S), the difference is not that large as it was with SVN 1.6 or older versions.

There are no major performance problems with HTTP(S) and up-to-date Subversion 1.7+ clients and servers.

HTTP(S) access with Subversion 1.7 became much more performant and especially on high-latency network connections thanks to HTTPv2 (do not confuse with HTTP/2!). Subversion 1.8 switched from libneon to libserf for HTTP(S) access and libserf provides better performance than libneon.

If there is some problem which you think is related to performance of HTTP(S) or Subversion working over HTTP(S), you should investigate whether there are any services on your network that make HTTP(S) slow. The root cause could be an antivirus, active firewall or proxy. Not to mention a misconfigured network settings. And don't forget to use up-to-date Subversion clients and servers!

Thinking of example of network misconfiguration, it seems that there is a pretty common problem which affects client computers working on disconnected networks that have no access to Windows Update site (http://ctldl.windowsupdate.com/). This is a critical problem that affects a wide range of system services, but end users notice and report it when using Subversion clients over HTTPS. The problem looks like it is related to performance, but it is not. Read this StackOverflow thread for more information: https://stackoverflow.com/a/38499619/761095.