Reputation: 47733
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?
Upvotes: 1
Views: 1117
Reputation: 12416
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.
Upvotes: 2
Reputation: 2533
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.
Upvotes: 2
Reputation: 12327
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.
Upvotes: 1
Reputation: 5644
I believe in creating a few repositories, each containing many related projects.
Upvotes: 3
Reputation: 573
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.
Upvotes: 1
Reputation: 35107
As a consultant I have multiple repositories so certain client's can't by some accident see/access another client's code.
Upvotes: 0