62

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"?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Earlz
  • 62,085
  • 98
  • 303
  • 499

6 Answers6

58

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.

Darryl Hein
  • 142,451
  • 95
  • 218
  • 261
Andreas Bonini
  • 44,018
  • 30
  • 122
  • 156
  • 5
    Another advantage of the http(s):// is that is conformant to the WebDAV standard. Which means you can mount such repositories in e.g. explorer or other WebDAV clients. See http://svnbook.red-bean.com/nightly/en/svn.webdav.html – Stefan Jan 27 '10 at 15:03
  • 5
    Svn is moving away from the WebDAV standard as of v1.7 due to the huge overhead involved and lack of WebDAV clients. – whitey04 Dec 14 '11 at 12:20
  • 2
    Downvoted because this answer is not actual anymore. SVN 1.7 and later greatly improve HTTP(S) usage and the difference between `svnserve`'s speed and HTTP(S) over Apache is not that large. – bahrep Aug 08 '16 at 15:13
22

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.

Adrian Smith
  • 17,236
  • 11
  • 71
  • 93
Thomas Pornin
  • 72,986
  • 14
  • 147
  • 189
7

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://.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Macha
  • 14,366
  • 14
  • 57
  • 69
  • 1
    I do not actually know a whole lot about svn+ssh. What kind of support does that require on the server? Must you have an ssh account that has a shell on the server? No anonymous access? – Earlz Jan 26 '10 at 16:53
  • SVN+SSH is basically the same as svn://, only you're conducting it through an SSH tunnel. This isn't an option you'd want to pursue if anonymous access is important to you. – Eric Kolb Jan 26 '10 at 16:58
  • @earlz: You need some kind of account with filesystem access to the repository, and the permission to run `svn` (or maybe some other binary?). – Thomas Jan 26 '10 at 16:59
  • @Eric: you can have anonymous access with SSH enabled if you want (not that you should or that it makes sense) – Andreas Bonini Jan 26 '10 at 16:59
  • @Andreas: True enough. I carry the implicit assumption that people intend to design security protocol based on what's sensible, so that caveat didn't spring to mind. :) That said, if public, anonymous, end-to-end-secure traffic is your aim with a subversion repository, HTTPS would be the smart choice for that. – Eric Kolb Jan 26 '10 at 17:36
5

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.

Community
  • 1
  • 1
bahrep
  • 29,961
  • 12
  • 103
  • 150
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

Ezz
  • 642
  • 6
  • 11
3

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).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Vestel
  • 1,005
  • 1
  • 11
  • 25
  • 2
    Well, you can have authentication with svnserve too.. It's just done in a slightly different way. – Andreas Bonini Jan 26 '10 at 16:57
  • Yes, and if you have 100 repositories for a same developer group, you need to transfer config file among any repository. This way, you can have only one file which allows them to access, and every change in it will control access to any repository – Vestel Jan 26 '10 at 17:01
  • You can obtain the same effect with svnserve + symlinks. Also, creating several repositories for the same developer group makes no sense and is discouraged from the official svn book. – Andreas Bonini Jan 26 '10 at 17:17
  • Example: I have a developer team (7 people) which works on several client projects. They must have access to repository and 'full live preview', which are located on one computer. No one else, should have any access to live preview. I can configure my apache the way, that only they got access to several folders and urls, and when one of developers leave team - I need to change access only in one place. – Vestel Jan 26 '10 at 17:44
  • 2
    With HTTP, it is much easier to use Windows Active Directory for authentication. This can be handy in a Windows environment. – myron-semack Jan 26 '10 at 18:08