Should I use one SVN repository for each website or create sub directorys for each site within a single repository?

Question

I'm currently in the process of setting up SVN on our local development web server and want to know if I should create a repository for each website on the server or a single repository that contains sub-directories for each site?

Thanks for your help.

Answer 1

If your "websites" share code among themselves you are better off with a single svn installation.

Answer 2

If there are dependencies between the websites then you should go for one repository because it will make it easier to rollback to stable releases and stuff like that.

If you have multiple completely detached websites you can go for different repositories. I don't anticipate any performance issues if you do so.

Answer 3

One repository under svn/repo works really well for me. I create a separate svn dir structure that includes at least a trunk dir under svn/repo/ for each website.

For example:

svn/repo
  /website1/trunk
  /website2/trunk
  /website3/trunk
  /website3/branches (if needed)
  /website3/tags (if needed)

In my experience:

• DRY - multiple repositories just create more tedious repetitive sys admin work
• KISS - one repo is the simplest solution without sacrificing capability
• You ain't gonna need it - Regardless of whether I'm working alone or with 10 devs, one repo always works and multiple repos cause headaches

Answer 4

In general I recommend a one project per repository model.

The potential downfall that some people have with this is needing multiple checkouts and sharing code etc.

Using code that's housed within another repository is very simple in svn using the svn:externals keyword. This allows you to pull in a directory from another repository into any given directory of your repository.

The gains you get with multiple repositories are multiple.

• SVN in particular slows down when working on a large checkout. All the normal commands will take noticeably longer in a very large checkout.

• If you start sharing work with other developers maintenance costs can increase as you may need to lock them out of some 'project directories' while giving them access to others.

• If you ever sell off a portion of your work, the buyer may request the source history. Splitting a large SVN repository is a very tedious effort, and in some cases may prove untenable.

• Simplicity. Multiple repositories can give you a very clear guideline on how to split up your code. This results in cleaner separation if used well, and therefore can act as an extension of your code's encapsulation.

As far as the server costs that was mentioned by Dave, it's very very possible to setup the server in such a fashion that logging into it and running svnadmin create in the right directory is enough to create a new repo.

Personal Experience

Backing up all these thoughts I'll share with you a little bit of my personal experience on the topic.

I'm also known as Kaelten, and I founded WowAce.com. Until recently we ran one of the largest shared svn repositories on the web. It had more than 82k revisions and more than 1.5k projects represented at various points in it's history for more than 3 million lines of code.

Disk space usage is substantial on a repository of this size, the revisions numbers lost meaning since they're all shared across all projects. In the end we had to come up with a system to split it up, chop that giant massive multi gigabyte repo into something small and usable.

In the end it caused me a lot more work to get it working sanely and split up than it did to set up a new system that worked sanely. WowAce.com and CurseForge.com still represent one of the largest selection of repositories of addons for WoW and a few other games, except now they're all split up in a nice sane fashion.