Using Subversion and Apache

Question

I've never used any kind of source control before although I understand the concept. What I am confused about (and perhaps just not aware) is what benefit do I achieve and/or why would I want to configure Subversion and Apache? Do I need to configure it with Apache to be able to access my repositories from other computers over a network? Please feel free to provide any other details you feel are relevant?

My setup right now is a laptop (XP Pro) and a virtual machine (XP Pro). On my virtual machine I have Apache 2.2, MySQL 5 and PHP 5. This setup is my main concern although I'm happy to hear examples/situations that deviate from my scenario.

P.S. Would this be a community wiki or a regular question? I'm not trying to rack up points or anything.

Answer 1

There's no need to set up Subversion with Apache. I've used Subversion for years and have never had to do so (although there are reasons why you would, mostly to do with authentication infrastructure). Since you're in a Windows world, I've seen that VisualSVN Server comes highly recommended and is easy to simply set up and go.

Answer 2

The situation I think you're getting at is if you want to use the WebDAV protocol to access your svn repository. In this case, you're basically allowing Apache to handle the file access as a intermediary to svn itself (no direct connections to the repo). I've heard this works pretty well, but there are several alternatives. Have a look at the SVN Book (check Google) for a starting point.

Answer 3

Using Apache, you can access your repository via webdav, that is over http on a standard port, so you can access/publish your repository behind corporates firewall for instance, which may not allow the svnserve port.

Answer 4

Check out the SVNBook Entry: Choosing a Server Configuration. It talks about the pros and cons of the different ways of accessing a Subverison server.

The SVN protocol is simplest to set up and administer, but probably won't work across corporate firewalls (but Apache will, via HTTP).

Answer 5

It can be beneficial when port 3690 needs to be closed. It also lets users browse the code using a browser, which has pros and cons, you don't need to have a subversion client to see the code, but a web browser makes a crummy repo browser.

Setting it up isn't too tricky. I found this page to be useful.

But, if you're just using it in a local vm environment, svnserve would be fine for you.

Answer 6

We use Subversion in a small team (6 people) enviroment, using the Visual SVN repository. Initially we didn't have an Apache web server, just IIS, but now we also run Apache, but there is no compelling reason to use Apache for the repository.

Answer 7

SVN can be a client server system, if you wish to share your code with other people, however if you want to work on your code alone(even from more than 1 computer!) you do not need any server at all!

You can use the file://-protocol build into nearly all svn clients and a local svn-repository.

Your svn-repository can also work from a network share, however you should use this approach only if you work on it alone!

Answer 8

You don't have to use Apache. There's a custom server svnserve.exe can be used instead. It runs on port 3690 by default but can be set to a different port by using the --port switch when setting it up.

Greg Hewgill gave you a link which will tell you what version of the Subversion server to use, and the different use cases. It basically boils down to svnserve if you don't need to integrate with any sort of authentication. Use Apache if you need more complex scenarios.

I have a commercial Windows console that handles svnserve. My profile has a link to see that utility. If you do decide that you use Apache, I recommend that you use VisualSVN Server.

Answer 9

The advantage to hosting your SVN repository through apache comes into play if you want ACLs on your repo.

You can configure basic authentication, and limit permissions on a per-directory (or per file if you feel the need) basis. For example, you can configure the repo to allow guest checkout, but any writing to the repo will require a specific, valid user.

A result of using apache to authenticate your users means that you don't have to define your users in a .htpasswd. Apache can hook into LDAP, most any type of SQL server, or even use Kerberos authentication.

Using the simplistic svnserve may well be enough. However, fine-grained permissions can't be applied and you won't be able to hook into another user database for authentication.

But from your description, all of the above may be overkill. The advantages apache offers are largely useless for a single user, and not worth the hassle.