Choosing a Subversion Server

Question

Hi,

After settling on Subversion as my RCS needs (and AnkhSVN/TortoiseSVN for my primary Subversion clients), I am trying to choose an SVN server. I have looked at a bunch of them:

• Local (ie file:///)
• Collabnet
• VisualSVN Server
• Tigris
• SilkSVN
• SharpSVN
• Apache module

I’ve installed each in a VM to try them out but have not found enough to differentiate most of them sufficiently to pick any specific. Now I have a few things I need to decide on.

1. protocol
2. vendor
3. SSL

1. I have read that HTTP is much slower than the SVN protocol. While my projects aren’t generally too big (really only the initial import is the time-consuming part), I do want to get the performance benefits of SVN, as well as avoid my HTTP logs being flooded with SVN entries (which I have as of yet been unable to segregate into a seprate LOG file).

I do however like the web interface that using an Apache module or VisualSVN affords. I don’t really need to provide my stuff to others (or even myself away from my system), so it isn’t critical, but it certainly allows for expandability.

2. After choosing a protocol (assuming I have to choose); I need help deciding what vendor to use. I originally used the Apache module from the Tigris distro. I have since removed that (well, just disabled it), and am currently using VisualSVN (which is HTTP and thus slow). I have seen people endorse Sharp and Silk but they seem to be smaller, indie distros.
Collabnet on the other hand seems to be more elaborate than I need. Basically, unless I can be convince for one of those, I am mainly just trying to choose between the official Tigris and VisualSVN.

3. I have also tried messing around with SSL without much success (I can’t afford a real CA, so I am using a self-signed cert in VisualSVN). I would be happy to use SVN+SSH/HTTPS, but if I am using it on my own system, then it’s not necessary, and if I use it externally, then my self-signed cert won’t help.

I suppose that I could even use a local repository; I would think that it would be the fastest. However I would prefer a more formal solution in case I expand. (I considered just using the TortiseSVN client to do the work of the server locally.)

So in summary, I need some advice on which server(s?) to use. What would be great is if I could get VisualSVN to provide an HTTP interface for web use, but also serve on an SVN protocol for use in the clients, preferably with the option of SSL on each. Is that possible? Would it be too much work (I really want to get back to working on my projects rather than all this meta-work).

Thanks a lot.

Edit

I thought I should give a little info on my circumstances to clarify things.

• (Currently) Single system, (older P4, Windows, 1GB SDRAM)
• (Currently) Single developer (me)
• (Currently) Relatively small projects (<2MB)
• Countless projects (>100 individual apps, games, libraries, web sites, etc.)
• Externals required (specifically my own library as well as 3rd party header, Boost, etc.)
• ? hmm, what else…

Answer 1

Edit: After reading the other answers here, there's one thing I thought I should mention. If you try one server, the repositories you ask it to serve will be no different from the repositories that you ask another type of server to serve.

In other words, if you decide to try one server now, you can switch to another type of server later, without losing your repositories. Of course, working copies, and any absolute external references you've made in your projects, will have to change, but you can keep your repositories with history and all.

---

I installed VisualSVN Server when it was announced, and was quite happy with it, for a while.

However, speed problems made me switch to the main svnserve server that is shipped as part of the Subversion command line package.

The main problem,is that I am working with .NET, and I chose to add several external Subversion references to my projects.

First, and foremost, every project I make in my class library is signed by my key. Second, external 3rd party libraries, like SQLite and NUnit was added as external references.

Every project had their own external references. I did this in order to be able to make a new application project, and then make new external references to the parts of my class library I needed, and for those references to be complete. If my class library solution in .NET had one external reference for the signing key file, and that file was not available as part of any single project, but was located on disk outside of all the projects, but local to my solution, that would not have worked.

So, my class library solution contains some 15-20 projects, each having at least one external reference to the signing key, all my data projects have external references to the SQLite library, and the unit test library having 4-5 external references.

The net result was that a single update at solution level, even if I already had all the latest files, directories, everything, took about 2 minutes to complete. Every single external references took somewhere between 10 and 20 seconds to complete, just to verify that I had the revision I needed.

When I switched to svnserve, those 2 minutes were reduced to about 3 seconds. This is local traffic mind you, so of course this will differ over the internet. The problem is, those 2 minutes were also local traffic.

So, while I absolutely loved the interface VisualSVN Server provided me with, including the ability to easily set up access rights and users, the speed that the Apache server module provided me with was absolutely horrible in comparison with what svnserve and the native Subversion protocol does.

Note that I have since then installed a separate Apache server, waded through lots of configuration files, and set up Subversion with Apache other than through VisualSVN server, just to ensure that it wasn't just VisualSVN, and I've confirmed that the speed I observed was not the work of the VisualSVN team. It seems the HTTP protocol or the Apache modules are just not that fast.

My advice is to go with the main svnserve server, if possible. It might take some work to get to know the configuration files for authorization and the likes, but the irritation factor alone (ie. no irritation over speed at all) will more than likely outweigh that.

Answer 2

I'm using CollabNet at home and at work. It's been fine - no complaints with performance.

Answer 3

Re access speed: I have seen an Apache https: SVN sever needing a hardware update. I seem to remember it was mainly lack of memory which slowed down the numerous Apache processes which competed for the machine's resources. But that was 20 developers collaborating on a project with a checked out tree of 20GB (lots of binaries in there, which often changed). And the update to a moderately equipped server solved the problem.

Also, in that very project, I had to learn that SVN on a ext3 FS under Linux was at leas an order of magnitude faster than on NTFS under Windows. Mark that: The Linux in a virtual machine running on Windows took a tenth of the time for an update competing with the Windows box the VM ran on. (We always meant to try that OS ext3 driver for Windows and see if this wouldn't make SVN faster on Windows than its native FS. However, I left the project before we ever got around trying.)

Anyway, it is not like what you decide for is cast into stone for eternity. You can try out one thing, test it thoroughly in a real project, and switch to a different server and protocol later. (There's even an SVN command to switch the URL of a checked out tree. This you can use to switch protocol without having to check out everything anew.)

Here's what I would consider to decide about the protocol: If you have a working AD or LDAP infrastructure that you would like to leverage for login into SVN, try one of the http/https: protocol options. If you don't have this, and you won't need it, and you are fine doing login by SVN's own means, why not use the speed provided by the svn: protocol?

I have never seen an SVN repo that people used WebDAV access to. IME they always want to have the history when accessing per web (WebDAV doesn't provide this, AFAIK), so they used one of the web frontends for SVN. I've never checked, but I just assume that stuff like ViewVC and the like don't care which protocol they use for accessing the repo.

As for which distribution you want to use -- I think that's mainly down to personal preferences, as the code underneath is the same anyway. I prefer downloads I don't have to register for and distributions that explicitly aim at the platform I want to install them on. But that's probably just me.

However, there's one hard fact you might want to consider if your repository is accessible from the Internet: When the SVN project made a new dot release, how long did it, in the past, take the different distributions to catch up. Since these might be security fixes, you might prefer the ones that, usually, provides the fixes faster.

Answer 4

We supply our SVN repositories using HTTP supplied by Apache running under CentOS 5.3 from inside a XEN virtual machine.

I'd observe that doing a commit or a checkout on a large file, transfers that file at close to network speed. Whilst checking out or commiting a large number of small files, the overhead of HTTP requests is much more noticeable.

Compared to the timescales in compiling code, SubVersion is not seen as a bottleneck inside the company.

(This is my experience with a team of 10 developers)