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/br
We are a small software company and we use a single repo for all of our development. The tree looks like this:
/client/<clientname>/<project>/<trunk, branches, tags>
The idea was that we would have client and internal work in the same repo, but we ended up having our company as a "client" of itself.
This has worked really well for us, and we use Trac to interface to it. Revision numbers are across the whole repo and not specific to one project, but that doesn't phase us.
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.
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.
We use a single repository. My only concern was scale, but after seeing ASF's repository (700k revisions and counting) I was pretty convinced performance would not be an issue.
Our projects are all related, different interlocking modules which form a set of dependencies for any given app. For this reason, a single repository is ideal. You may want seperate trunk/branches/tags for each project, but you're still able to atomically commit a change across your entire codebase within a single revision. This is awesome for refactoring.
I would create separate repositories... Why? The revision numbers and commit messages will just not make any sense if you have a lot of unrelated projects in only one repository, it will be for sure a big mess in short term....
Be aware that when making your decision, many SVN repos can share the same config file.
Example (taken from link above):
In shell:
$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3
File: /var/svn/repos1/conf/svnserve.conf
[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository
File: /var/svn/conf/authz
[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4
### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw
### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw
### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw
### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw