Which subversion server type is best?

Question

Subversion has multiple server types:

• svnserve daemon
• svnserve via xinetd
• svn over ssh
• http-based server
• direct access via file:/// URLs

Which one of these is best for a small Linux system (one to two users)?

Answer 1

I like sliksvn runs as a service in Windows, 2mins to setup and then forget about it.
It also comes with the client tools but download tortoise as well.

Answer 2

I've always used XInetD and HTTP. HTTP also had WebDAV going on, so I could browse the source online if I wanted (or you can require a VPN if you wanted encryption and a dark-net type thing).

It really depends on what restrictions (if any) you're under.

Is it only going to be on a LAN? Will you need access outside of your LAN? If so, will you have a VPN? Do you have a static IP address and are you allowed to forward ports?

If you aren't under any restriction, I would then suggest going with xinetd (if you have xientd installed, daemon if you don't) and then (if you need remote access) use http-based server if you need remote access (you can also encrypt using HTTPS if you don't want plain text un/pw sent across).

Most other options are more effort with less benefit.

It's an SVN Repo -- you can always pack your bags and change things if you don't like it.

Answer 3

1 of those options is definitely a 'worst' one: file access. Don't use it, use one of the server-based methods instead.

However, whether to use HTTP or Svnserve is entirely a matter of preference. In fact, you can use both simultaneously, the write-lock on the repo ensures that you won't corrupt anything if you use one and then use another.

My preference is simply to use apache though - http is more firewall and internet friendly, it is also easier to hook into ldap or other authentication mechanisms, and you get features like webdav too. The performance may be less than svnserve, but its not particularly noticeable (the transferring of data across the network makes up the bulk of any performance issues)

If you need security for file transfers, then svnserve+ssh, or apache over https is your choice.

Answer 4

If you are going to be using the server only on the local machine and understand unix permissions, using file:// urls will be fast, simple and secure. Likewise, if you understand unix permissions and ssh and need to access it remotely, ssh will work great. While I see somebody else mentions it as "worst", I'm pretty sure that's simply due to the need to understand unix permissions.

If you do not like or understand unix permissions, you need to go with svnserve or http. I would probably choose to run it in xinetd, personally.

Finally, if you have firewall or proxy issues, you may need to consider using http. It's much more complicated, and i don't think you're going to see the benefits, so I'd put it last on your list.

Answer 5

I would recommend the http option, since I'm currently using svn+ssh and it appears to be the red-headed stepchild of the available protocols: 3rd-party tool support is consistently worse for svn+ssh than it is for http.

Answer 6

Check out FLOSS Weekly Episode 28. Greg Stein is one of the inventors of the WebDAV protocol for SVN and discusses the tradeoffs. My takeaway is that SVN: is faster but the http/webdav implementation is just fine for almost all purposes.

Answer 7

I've been responsible for administering both svnserve and Apache+SVN for my development teams, and I prefer the http-based solution for its flexibility. I know next to little about system administration, I'm a software guy after all, and I liked being able to hand authentication and authorization over to Apache.

Both tines the teams were about 10~15 people and both methods worked equally well. If you're planning for any expansion in the future, you might consider the http-based solution. It's just as easy to configure as svnserve, and if you're not going to expose the server to the Internet then you don't have to worry too much about securing and administering Apache either.

As a user of SVN, I prefer the http-based integration with Apache. I like being able to browse the repository with my web browser.

Answer 8

For ease of administration and security, we use svn+ssh for anything that requires commit access. We have set up HTTP based access for anonymous (read only) access to some open-source code, and it is much faster; the problem with svn+ssh is that it has to start up an ssh connection and a whole new svnserve for each user for every operation, which can get to be pretty slow after a while.

So, I'd recommend:

• http for anonymous connections
• svn+ssh if you need something secure and relatively quick and easy (assuming your users already have ssh set up and your users have access to the server)
• https if you need something faster, secure, and you don't mind the extra overhead of administering it (or if you don't already have ssh set up or don't want to deal with Unix permissions)

Answer 9

http:

• very flexible and easy for administration
• no network problems (Port 80)
• 3rd party authentication (eg. LDAP, Active Directory)
• Unix + Win native support
• webdav support for editing without svn client
• slow, as each action triggers a new http-action approx. 5-8 times slower than svn://
• especially slow on history
• no encryption of transferred data

https:

• same as http
• encryption of transferred data

svn:

• fastest transfer
• no password encryption in std. setup: pw are readable by admin
• firewall problems as no std.port is used
• daemon service has to be started
• no encryption of transferred data

svn+ssh

• nearly as fast as svn://
• no windows OS comes with build in ssh components, so 3rd party tools are essentiell
• no daemon service needed
• encryption of passwords
• encryption of transfer

Answer 10

I am curious why NOT FSFS?? Important information - I am managing Windows systems.

I have done many projects with SVN and almost all of them were running from FSFS. Biggest repository was around 70GB (extreme), biggest ammount of repositories was around 700.

We never had any issues, even though we hosted it on Windows, NetApp and many other storage systems. Most of the time when I asked why NOT using FSFS only problem was that people simply didn't trust it.

Advantages: 1.) No backend required (or dedicated server) 2.) Fast and reliable 3.) Hook scripts are supported 4.) NTFS permissions are used 5.) Easy to understand, easy to support, easy to manage

Disadvantages: 1.) Not so easy access from outside your network (VPN) 2.) Permissions only on repository-level (Read, Read/Write) 3.) Hook scripts are running under current user credentials (which is sometimes advantage, sometimes disadvantage)

Martin