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.
Similar to Blade's suggestion about sharing files, here is a slightly easier, yet less flexible solution. I setup ours like so:
In "bin", I keep a script called svn-create.sh which will do all of the setup work of creating an empty repository. I also keep the backup script there.
In "repository_files", I keep common "conf" and "hooks" directories that all of the repositories have sym links to. Then, there's only one set of files. This does eliminate the ability to have granular, per-project access without breaking the links, though. That was not a concern where I set this up.
Last, I keep the main directory /var/svn under source control ignoring everything in svnroot. That way the repository files and scripts are under source control as well.
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
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!
If you plan to or use tool like trac wich integrate with SVN, it makes more sense to use one repo per project.
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.
Similar to mlambie's of using a single repo, but went bit further with the folder structure to easily zoom to particular type of projects - web html based projects vs. cs (C#) vs. sql (SQL create/execute scripts) vs. xyz (Domain Specific Languages like afl (AmiBroker Formula Language) or ts (TradeStation)):
Note, I have trunk live within branches as I treat it as the default branch. The only pain sometimes is when you want to quickly create another project you need to build out the ProjectName/branches|tags structure. I use app-settings simply as place to keep specific Apps settings files in repo so easily shareable to others (and substitute ClientName to VendorName and ProjectName to AppName in this folder structure; and the branches|tags can be useful to tag settings across different major versions of vendor products too).
Welcome to any comments on my structure - I recently changed it to this and so far pretty happy but sometimes find it burdensome to maintain branches|tags structures per project - particularly if the project is simply a project setup simply to Unit Test another project.
Be aware that when making your decision, many SVN repos can share the same config file.
Example (taken from link above):
In shell:
File: /var/svn/repos1/conf/svnserve.conf
File: /var/svn/conf/authz