Repository Structure with Tortoise SVN Question

Question

Most people structure their repositories as so, which is best practice

MainRepository
    Project1
       branches
       trunk
       tags
    Project2
       branches
       trunk
       tags
..and so on

would there ever be a need to create a second repository? I think most people have lived with only one as best practice and would never need to create a second, is that correct? Or are there some circumstances where you might want to create more than one?

Answer 1

As a consultant I have multiple repositories so certain client's can't by some accident see/access another client's code.

Answer 2

Having done it both ways I find it more painful to have multiple repositories. More places to manage access etc...

That being said I believe a group should manage their own repository and it shouldn't be at a enterprise level.

Answer 3

I believe in creating a few repositories, each containing many related projects.

Answer 4

We keep our projects completely separate. It is nice to have a single revision number to spread across multiple related projects, but as a former IT manager I'm too paranoid about corruptions and failures to stack everything into one "basket", as it were.

Answer 5

Creating separate repositories for each project is useful for managing the lifetime of repositories. With the new 1.6 version of subversion, you can "svnadmin pack" a repository for optimized access. Also, moving repositories between servers is easier when you have granularity.

Having separate repositories in a high traffic environment is good for load balancing as well if you want to split them between two servers or put them on different physical disks. If you had all projects in one repository, then you would need to do a backup and run the svndumpfilter tool to filter out the parts of the tree you didn't want. If you had any branching across projects, this would have some issues when it tries to restore the data as the source path is no longer available.

Answer 6

I'm all for one repository per kind of data. So all source code & vendor libraries would go into one repository, another repository for the build results and releases. Another repository for deployment libraries. Another repository for company documents, etc.

Basically, separate repositories when the rules for using the repository change. This lets you be flexible with layouts and hooks and authorization, etc.

Eg, you want your sales team's word docs under source control? Fine idea, but you probably don't need trunk/tags/branches and the users that access it are very different. The structure would be completely different, so suddenly it doesn't make sense to even try to relate it to the source code repository.

Some people use multiple physical repositories for their source code. In my head I think of that as a single meta-repository where the data's sharded for convenience, performance or security concerns.