Subversion – SVN
Subversion aka SVN is a very popular source control system. A lot of people have asked about using SVN+SSH as an “easy” way to setup an svn server. I feel that using https is a much better choice for several reasons.
In a nutshell, SVN+SSH has security issues. While it secures the communication, it leaves the repository itself vulnerable to every user, who can accidentally damage any or all of the repository. SVN+SSH also has potential file-locking issues. It is more of an SSH over the file:// protocol than it is SSH over SVNSERVE. See below for more detail.
In addition, SVN+SSH has NO LOGGING of activity. If the server starts to have problems, you don’t get any useful information, because SVN+SSH isn’t actually using a server, it’s really just filesystem access. SVN+SSH has higher TCO because you have to maintain SSH accounts for each user.
Apache setup is slightly more difficult, but still usually under an hour for a complete install from scratch, or you can do it easier by downloading a stack from VM ready to go from places like Bitnami. Ongoing apache is much easier to maintain, is more secure, more flexible, provides more options, has logging, and many other features outlined in the attached docs.
Let’s take a look at the variety of ways in which you can access an SVN repository. Each has advantages and disadvantages, but the apache method is the most common among enterprise users because of it’s flexibility, security, and rich feature set.
It’s a bit more complex than some of the others initially, but still a whole lot easier than some other systems out there like ClearCase. A novice following any of the many tutorials should be up in less than an hour. Ongoing administration is actually easier than some of the others, providing a lower TCO.
“The most common problem administrators run into is repository ownership and permissions.” SVN Book: Supporting Multiple Repository Access Methods
A list of the models and a brief summary for each follows.
• apache aka webdav
• svn+ssh SVN over ssh
• svnserve daemon
• svnserve via xinetd or as a windows service
• file:// access the repository directly without any server
apache
Using SVN with the webdav apache plugin is one of the most common ways to setup an SVN server. The advantage is that it’s almost as easy to setup as the other modes, but provides much better security and actually less ongoing administration. Using https makes it slightly more difficult – mostly because you need to setup a certificate if you don’t already have one. Adding a self-signed certificate to my own SVN setup took me about 15 minutes.
This method has additional capabilities around access control, and can even use existing directory services such as LDAP. svn+ssh only allows access control to the whole repository. It’s also the only server model that has logging to keep track of errors and usage. (SVN book chapter 6 – server configuration Table 6.1 – comparison of server options)
Additionally there are some neat things about having a web server with your SVN, like getting a repository browser for “free” (IE no extra effort) which is really helpful when people want to discuss items in source control without necessarily checking them out.
Bottom line, webdav is the best bet, since it uses a multithreaded server that can handle concurrency without corrupting your database. Apache also supports authentication with client certificates, if you’re concerned about security. (see also Using svn over ssh and the SVN book chapter 5, section 4)
svn+ssh
svn+ssh can be thought of as a remote-enabled version of the file:// protocol, rather than a secure version of svnserve since it really isn’t using svnserve.
“It’s essentially the same as a local user accessing the repository via file:// URLs.” from the SVN book chapter 6 – svnserve over a tunnel
It adds security to an SVN implementation, but at the cost of system performance (which is the one real advantage of the non-apache models). It also has ongoing administration issues, as well as some potential problems with concurrency. Generally only recommended for installations that already have an existing ssh account infrastructure, and even then recommended with the following caveat from the SVN book chapter 6: no logging, not even errors. All users have to be in the same system group or used a shared SSH key, and if used improperly can lead to file permission problems. Requires real system accounts on the server host, leading to higher TCO.
Another potential security issue is that with actual SSH accounts, the users can login to the SVN server and delete the entire repository, because of how file permissions have to be setup for this model.
The SVN book recommendation section essentially reads that if you already have an infrastructure it makes sense, but we (the SVN people) don’t widely recommend this option. Further
“… we warn against accessing repositories via svn+ssh:// URLs_from a security standpoint, it’s effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn’t careful.”
svnserve operates directly on the repository files (using file:/// urls), which means if you ever have two svnserve processes running at the same time (NOTE: this is standard for svn+ssh), you can get contention, which usually results in a locked repository that has to be taken offline, repaired, and reenabled.
svnserve
svnserve is relatively simple to setup and fast. But isn’t not secure at all. There are potential permissions issues, leading to ongoing administration headaches. It’s only recommended for small teams just getting started. From the SVN book chapter 6: no logging, no web browsing, no encryption, clear-text passwords. If that doesn’t make you nervous, then go ahead.
xinetd or a windows service
Essentially the same as svnserve by itself (see previous paragraph), except that the daemon is fired “on-demand” which could potentially save some small amount of system resources. On windows you can do the same thing running svnserve as a windows service.
file://
Using the direct access method is not multi-user and not secure. Super fast easy setup, because there is none. Not supported by some clients and third-party tools. It’s not even listed under the section for server setup in the SVN book.
Essentially this is an easy way to learn how to deal with subversion or perhaps setup a single person SVN installation. However if there are any long-term plans, going the few extra steps to setup an actual server are highly recommended. It’s best to think of this as a testing method rather than a deployment model.
If you have further questions, let me know and I’ll try to help. If you’d like to hear about other source controls systems, send me your suggestions.