Multiple SVN Repositories or single company reposi

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

It all depends on how many projects you have, the size of your organisation, how related the projects are, and so on. If you're part of a large team with a couple of dozen projects, a repository per project is going to be pretty unwieldy to administer.

Depending on what type of work your organisation does, another option is to have one repository per client. Where I work, we currently have four repositories - one for projects that are completely internal to us, one for the software we sell, and two that are completely specific to particular clients for whom we produce custom software applicable only to them. This is an attempt at a 'best of both worlds' solution - we don't have one massive repository that contains everything and has a revision number in the billions (I exaggerate obviously!), but nor do we have dozens of piddly little repositories lying around with one project in each.

Answer 3

If you are using Subversion, you could have multiple repositories under the same domain with multiple projects each.

So it'd look like this

Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2

Project1 might address front-end code and contains sub-projects such as admin/ and web/ Project2 would be backend and contains various tools and monitoring applications

If you use something like Git, each repository should be a single project.

Answer 4

I am working at a company which works for a lot of customers with strict rules. At the moment we have around 130 developers. We have a core project which is customized to each customers needs. And we have one huge svn repository. It would be pain in the ass if we would have to check out the whole branch but our strategy is to move the projects out of the common branch and leave the work only for the switch commands. :) This way everything can be kept in a single repository.

My only concern was the splitting of a repository to multiple repositories if needed in case of outsorcing part of the work, or selling a whole project until I found this: http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories

So I think svn switch eases the pain of long checkout (one switches out only the desired projects), yet we can have one repository. But, if still needed, one can extract a set of components to separate repository.

Answer 5

For my organization I went midway, creating several repositories for different coding "areas". I knew in advance that each repository would contain projects that would be fairly separate from each other.

Answer 6

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).