Over a million developers have joined DZone.

Subversion (SVN): One Repository vs Many

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

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:
subversion

Published at DZone with permission of Eva Johnson. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}