Over a million developers have joined DZone.

Subversion (SVN): One Repository vs Many

DZone's Guide to

Subversion (SVN): One Repository vs Many

How to determine whether you should adapt several Subversion repositories or just one.

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

A common question from our business clients is how to structure their projects with Subversion (SVN), whether to go with one repository or many. The quick answer is that it is purely a matter of access control and maintenance, however this answer is a rather simplistic one at best and it has a rather more complex answer than it sounds. We created a simple survey below to help you find your.

Which is Best For Your Business, a Single Repository or Many?

It is in part a question of size, how many projects, and how many programmers. For a larger enterprise with many hundreds or thousands of projects and programmers, the answer is always going to be many repositories. Why? Simply because the pressures exerted by large numbers of users sets the priority to access control and maintenance above all other considerations. This is especially true for software development in mission critical industries where industry standards enforce traceability. There are exceptions to all the above of course, for example some open source repositories such as Apache use a single repository.

For smaller companies the answer is not so clear cut, there are many other considerations to be made. Below is a series of simple questions that should be asked of your business, the yes or no answers should impact on your decision as to whether to go with a single repository or many.

  1. Do you want to limit access to certain projects to some teams or individuals but not others?
  2. Do you have more than 50 simultaneous projects?
  3. Do you have the budget for more than one respository?
  4. Is it likely that you will need to segregate a clients project code from the repository due to client security concerns?
  5. Do you have an employee designated to, – or can you assign one with the task of repository (or repositories) maintenence?
  6. Is this statement true: You are unlikely to need to commit changes across the entire code base (all projects)?
  7. Will you be integrating your repos with tools such as Application Lifecycle software (ALM software)?
  8. Do you have complex standards to adhere to and be compliant with on your projects?
  9. Is this true: Is your code NOT open source or you have a mix of projects, some are but others are not open source?
  10. Is this true: Are your projects NOT similar?

With a single repository it is easier to move code between projects, this is of particular interest for companies that produce a similar product range where the code is very similar between the products. In such situations it is also simpler to tag and branch multiple projects and where code is moved around you can retain the history of the code.

Of course, every business is different,so these questions need to be prioritized, which of these questions are the most important to your business? Whatever your priority, if you have multiple questions with the answer YES then the multi-repository option is more likely to be the best option.

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}