Where should a Subversion repository be?

Question

Should it be on the development servers or a Subversion server?

I suppose this could be expanded to any client-server version control system.

Answer 1

The physical repository should be on a stable system that gets regular backups.

Generally, a development server does not fit this description... it may be acceptable to put the apache server on the dev server and host the files remotely on a stable, backed-up file server (though there are a number of pitfalls with this approach) if you are unable to get additional server resources. Hosting it on the dev server may be fine if you have an aggressive backup system to protect your code...

Just keep in mind that dev servers are prone to configuration changes, being blown-away, or otherwise mucked with that could take down your repo at a critical moment.

Answer 2

I keep mine on the development server, which also runs Trac, Apache hosting an automatically-updated copy of the project JavaDocs, and the CI build platform. A project would have to be of fairly epic proportions to require a dedicated Subversion server.

However, keep in mind that it is very important to keep your Subversion repository backed up on another machine in another location - your repository is your most valuable asset!

Answer 3

I like to keep mine on its own server, only because in my view its one of the most important servers in an organization, and keeping it on its own server helps admins do backups and other maintenance activities. And because the server is so important you don't want to have other developers mucking around on it in any way that could compromise it by accident.

Also if you have a bunch of developers and an active continuous-integration server running you could actually spike the cpu quite a bit and the last thing you want to do is have anything standing in the way of you committing your code changes

Answer 4

Development boxes will, by definition, get trashed and fall over. It comes with the territory!

Do you really want this to happen to your source code repositories?...

Answer 5

In addition to what other people mentioned about dev servers being trashed regularly, there is a performance argument too. If someone is doing some development or testing on the development server, you don't want that to slow down the SVN server for checkouts or synchronizations. Also if you decide to run something like continuous integration on the same server, you don't want all your unit tests to bog down regular dev/test operations on that server.

Answer 6

At my firm we put it on a dedicated machine that provides redundant storage. I guess in our culture we put high value on the source and the time and effort it takes to create our source codes. We never put on any kind of testing machine that might become damanged or wiped clean because the configuration became unmanageable.

woops. we also keep our defect tracking on the same box but for the same reason.

Answer 7

We use a clean, blank slate for our repositories. Specifically, we use Slicehost for our main repository.

We started with a 256MB slice and upgraded later on to 512MB. Slicehost is great because you know you have a completely clean server to start with, and can build the things you need on your own.

Slicehosts' articles are top-notch.

Our repo server looks like this:

• Ubuntu Hardy Heron
• Subversion
• Apache
• Ruby on Rails
• Warehouse
• Passenger to serve Warehouse via Apache
• Daily and weekly backups through Slicehost

And that's about it. Not much overhead.

Edit: Not trying to sell Slicehost here, so if that's not kosher, let me know!

Edit again: James makes an excellent point about hosting proprietary code on a third-party server. Extra care should certainly be taken when selecting a host to do such a thing. Unfortunately, many companies simply don't have the resources to build and manage servers in house, which is where we found ourselves prior to selecting a host for our code.