Multiple SVN Repositories or single company repository

Question

Should we have one single repository for all the company, which contains many development projects, or a repository per project? Any ideas on experience / best practice?

Answer 1

I've found that having a single Subversion repository aids in:

1. Transparency: it is easier to follow what is going on, and find code even in projects you may not be directly involved in.
2. Maintenance: it is not necessary to create repositories every time you wish to create a new project, and you can delete entire projects without fear of losing the record from Subversion.
3. Maintenance: it is only necessary to have one repository backed up.

EDIT: Additional reasons:

• Global revision ids - by having revision ids be global it is:
  1. Easier to communicate (e.g. in a code review request, just specify the revision id, without a need to specify which project).
  2. Easier to guarantee atomicity when projects have dependencies on each other.
  3. Easier to see the order of commits to different projects.

Answer 2

Personally I would definitely prefer separate repository per project. There are several reasons:

1. Revision numbers. Each project repository will have separate revisions sequence.

2. Granularity. With repository per project you just can't make a commit into different projects having the same revision number. I assume this more as advantage, while someone would say that it is a flaw.

3. Repository size. How large is your project? Does it have binaries under source control? I bet it has. Therefore, size is important - each revision of binary file increases size of the repository. Eventually it becomes clumsy and it's hard to support. Fine-grained policy of binary files storage should be supported, and additional administration provided. As for me, I still can't find how could I completely delete binary file (committed by some stupid user) and its contents history from repository. With repository per project it would be easier.

4. Inner repository organization. I prefer fine-grained, very organized, self contained, structured repositories. There is a diagram illustrating general (ideal) approach of repository maintenance process. I think you would agree that it is just NOT POSSIBLE to use 'all projects in one repo' approach. For example, my initial structure of repository (every project repository should have) is:

   /project     /trunk     /tags         /builds             /PA             /A             /B         /releases             /AR             /BR             /RC             /ST     /branches         /experimental         /maintenance             /versions             /platforms         /releases 

5. Repo administration. 'Repository per project' has more possibilities in users access configuration. It is more complex though. But there is also helpful feature: you can configure repositories to use the same config file

6. Repo Support. I prefer backing up repositories separately. Somebody says that in this case it is not possible to merge info from one repo into the other. Why on earth you would need that? The case when such merge is required shows that initial approach to source control is wrong. Evolution of the project assumes subsequent project separation into submodules, not the other way. And I know that there is approach to do that.

7. svn:externals. 'Repository per project' approach encourages svn:externals usage. That is a healthy situation when dependencies between project and submodules is established via soft links, which svn:externals is.

   Conclusion. If you want to keep source control simple, use one repository. If you want to make software configuration management RIGHT:

   1. Use 'repository per project' approach
   2. Introduce separate role of software configuration manager and assign team member to it
   3. Hire good administrator, who can cope with all subversion tricks :)

PS. By the way, in spite I work with SVN all the time and I like it, 'repository per project' approach is why I see DCVS systems more attractive from the repository organization point of view. In DCVS repo is the project by default. There is even no question 'single vs multiple' possible, it would be just nonsense.