Multiple SVN Repositories or single company repository

Solution 1:

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

Transparency: it is easier to follow what is going on, and find code even in projects you may not be directly involved in.
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.
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.

Solution 2:

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

Revision numbers. Each project repository will have separate revisions sequence.
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.
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.
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
```
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
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.
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.

Solution 3:

I strongly recommend not using a repository per project. Within a single subversion repository, you can move and copy data and it will retain its history. If you decide that some piece of code that started as a backend tool is being merged into the front end, and those are in different repositories, this isn't an operation that subversion will know anything about. It will be as if you added something to the front end from no where. This also means that you can't do merges if you need to temporarily maintain two versions of related code.

You will note that all the examples in the svn book assume everything is in one repository.

There's a separate question of whether to use /trunk/project1, /trunk/project2, /branches/project1-r1 or to use /project1/trunk, /project1/branches/r1, /project2/trunk. Generally, the second is easier to keep track of.

The best reason to not put everything in one repository is that access control is hard to do more finely grained than at the repository level. Possible, yes, but not as easy. We currently have two main repositories:

svn/code for all software development, requires jira ticket to commit
svn/ops for any config, set up scripts, third party tars, whatever, no jira required

Solution 4:

It would depend on how interdependent your applications/projects are in the organization, and also how big the codebases are.So it boils down to how one defines a "project" in your organization. Shared codebase, shared components, shared teams, shared release cycles, could all influence how your repositories need be structured.

For simplicity, I define a project as having an independent codebase, release timeline, and/or belonging to one tool/application.If this is the case, I prefer having one repository per project. This way there is more freedom to define and implement policies/access restrictions per project.

If I had a single repository bloating over time ..I may also need to worry about the workspace checkout time etc., especially if the code for the projects are all mixed. If an application/tool/project is completed/shelved/obsoleted/migrated, there can be more control on the administration aspects if there is separation at project level.

Structuring a project repository based on its unique needs can also be easier if there is one repository per project. Each project may have specific needs, which may affect the configuration management policies (branching, tagging, naming conventions, CI etc included) followed for each project. This is not to say you cannot do all of this folder-wise within a single repository. You can. It just keeps things simpler to have a cleaner separation - that is all.

You may want to consider all these factors in order to evaluate the administrative overheads you may end up with, based on your specific setup.

This said, if the projects are all small in size, and are interdependent , requiring cross references, cross tracking, movement within each other etc., then you are better off with a single repo and one folder per repository.

Solution 5:

I would have a repository for project, just for the sake of the revision numbers being per-project. You can setup SVN to be served so that all of the projects can be accessed from a single access point using Apache and DAV SVN (with SVNParentPath directive).