One SVN repository or many?

If you have multiple, unrelated projects, is it a good idea to put them in the same repository?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

or would you create new repositories for each?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

What are the pros and cons of each? All that I can currently think of is that you get mixed revision numbers (so what?), and that you can't use svn:externals unless the repository is actually external. (i think?)

The reason I ask is because I'm considering consolidating my multiple repos into one, since my SVN host has started charging per repo.

Solution 1:

The single vs. multiple issue comes down to personal or organizational preference.

Management of multiple vs. single mainly comes down to access control and maintenance.

Access control for a single repository can be contained in a single file; Multiple repositories are may require multiple files. Maintenance has similar issues - one big backup, or a lot of little backups.

I manage my own. There's one repository, multiple projects, each with its own tags, trunk and branches. If one gets too big or I need to physically isolate a customer's code for their comfort, I can quickly and easily create a new repository.

I recently consulted with a relatively large firm on migrating multiple source code control systems to Subversion. They have ~50 projects, ranging from very small to enterprise applications and their corporate website. Their plan? Start with a single repository, migrate to multiple if necessary. The migration is almost complete and they're still on a single repository, no complaints or issues reported due to it being a single repository.

This isn't a binary, black & white issue.

Do what works for you - were I in your position, I'd combine projects into a single repository as fast as I could type the commands, because the cost would be a major consideration in my (very, very small) company.

JFTR:

revision numbers in Subversion really have no meaning outside the repository. If you need meaningful names for a revision, create a TAG

Commit messages are easily filtered by path in the repository, so reading only those related to a particular project is a trivial exercise.

Edit: See Blade's response for details on using a single authorization/authentication configuration for SVN.

Solution 2:

For your specific case one(1) repository is perfect. You will save a lot of money. I always encourage people to use a single repository. Because it is similar to a single filesystem: It is easier

• You will have a single place where you look for code
• You will have a single authorisation
• You will have a single commit number(ever tried to build a project which is spread over 3 repos?)
• You can better reuse common libraries and track your progress in these libs(svn:externals are PITA and will not solve all problems)
• Projects planned as fully different items, can grow together and share functions and interfaces. This will be very difficult to achieve in multiple repos.

There is a single point for multiple repositories: administration of huge repos is uncomfortable. Dumping/loading huge repos takes a lot of time. But as you do not do any administration, I think it will not be your concern ;)

SVN scales very well with bigger repositories, there is no slowdown even on huge (>100GB) repositories.

So you will have less hassle with a single repository. But you really should think about the repo layout!

Solution 3:

I would use multiple repositories. In addition to the user access issue, it also makes backup and restore easier. And if you find yourself in a position where somebody wants to pay you for your code (and its history), it's easier to give them just a repository dump.

I would suggest that consolidating repositories just because of the charging policies of your hosting provider is not a very good reason.