Choosing a Subversion Server

Question

After choosing Apache Subversion for my version control needs (and AnkhSVN / TortoiseSVN for my primary Subversion clients). Now I am trying to choose the SVN server to provide remote access to SVN repositories. I have looked at a couple of them :

• CollabNet Subversion Edge
• VisualSVN Server

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.