Single Repository or Many?

My previous blog entry discussed the issue of repository layout. This entry will try to answer the question of whether you should have one repository per project or a single repository that houses all your projects. There is not going to be a single right answer to this question. Hopefully this post will help you understand the tradeoffs so you can make the right decision that suits your requirements. These are some of the advantages of the single repository approach.

1. Simplified administration. One set of hooks to deploy. One repository to backup. etc.

2. Branch/tag flexibility. With the code all in one repository it makes it easier to create a branch or tag involving multiple projects.

3. Move code easily. Perhaps you want to take a section of code from one project and use it in another, or turn it into a library for several projects. It is easy to move the code within the same repository and retain the history of the code in the process.

Here are some of the drawbacks to the single repository approach, advantages to the multiple repository approach.

1. Size. It might be easier to deal with many smaller repositories than one large one. For example, if you retire a project you can just archive the repository to media and remove it from the disk and free up the storage. Maybe you need to dump/load a repository for some reason, such as to take advantage of a new Subversion feature. This is easier to do and with less impact if it is a smaller repository. Even if you eventually want to do it to all of your repositories, it will have less impact to do them one at a time, assuming there is not a pressing need to do them all at once.

2. Global revision number. Even though this should not be an issue, some people perceive it to be one and do not like to see the revision number advance on the repository and for inactive projects to have large gaps in their revision history.

3. Access control. While Subversion’s authz mechanism allows you to restrict access as needed to parts of the repository, it is still easier to do this at the repository level. If you have a project that only a select few individuals should access, this is easier to do with a single repository for that project.

4. Administrative flexibility. If you have multiple repositories, then it is easier to implement different hook scripts based on the needs of the repository/projects. If you want uniform hook scripts, then a single repository might be better, but if each project wants its own commit email style then it is easier to have those projects in separate repositories

This is just a sampling of the pros and cons of each approach. Hopefully it gives you something to go on to make a decision. I tend to prefer the one repository per project approach with the caveat that if I have many projects that are related to each other, I would put those all in the same repository. I also tend to break up repositories by group or team, although in reality this is just a variation of the project concept.

For example, I had one repository for the Documentation department to use for their projects. Of course in the case of on-line help that was often located in the same project as the application code, but the Documentation team also had other materials they produced and I gave them a repository for that. Likewise, the Marketing department had a repository to store the things they worked on, including the company web site. As was the case with the layout of the repository, this is really just a decision of what will work best for you. That  said, it is a little more difficult to change your repository setup after the fact.

So, it is worth it to take some time to understand your requirements and which approach best suits them.

Mark Phippard

Engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations. Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project. Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.

Tagged with: , , , , , , , , , , , , , , , ,
Posted in Subversion
8 comments on “Single Repository or Many?
  1. John says:

    Another consideration also has to do with resources between the development team(s) and the system administrators.
    I’m sure my company is like many other companies, where there are development teams in different geographic areas, but there is a centralized system administration / data center team that manages the servers – including the subversion servers.
    we have two subversion servers for our company – one dev and one production. Yes, it sounds odd calling a subversion server used by developers a “production box”, but think of it from the sys admin perspective: these guys have to maintain 24/7 support for this box so that development doesn’t get held up! Being a “production box” also means developers (like me) do *not* have rights on the box to upgrade or create repos.
    Since we have a centralized sys admin group for this, the one bit of drudgery is that all repositories need to be requested through our Remedy ticketing system – that is, not just saying “hey Ted, can you create a repository for me real quick”. Therefore, it’s easier for us to put multiple projects in one repository, than to always have to wait to have repositories set up for us.
    We have 30-40 distict projects set up in our repository, and there are probably 10-15 groups in my company like ours. One repository suits our needs

  2. PaMS says:

    Can you pls explain – that how to create many/multiple repository?

  3. When you setup a SVN server, whether Apache or svnserve, the typical way to do it is to point the server at a folder that contains many repositories. For example:
    C:repositories
    repos1
    repos2
    repos3
    To create the repositories, you just use the svnadmin command to create more repositories in that folder.
    Mark

  4. Ajish says:

    I am planning to use SVN (Tortoise SVN) as a back-up tool for a team of 25 sw developers. The idea is to use it only for a daily backup and not for Configuration Management. I am thinking of creating a repository for each developer and I am confused about two things:
    1)For user login, I am creating a ‘userfile’ in the ‘conf’ directory in each repository and this ‘userfile’ will contain the username and password for the user of the repository. But the users are worried that this is a simple aproach and they dont want even the administrator to know their password. Is there a better way to do it?
    2)How can I restrict the Repository size for each user ?? I dont want the user to put unwanted files into the SVN folder and cause hard disk space contraints.
    I hope someone can give me anwers for this.Thanks in advance.

  5. Ajish,
    There are a number of discussion forums on openCollabNet which are a much better place to carry on a conversation and ask questions.
    http://forums.open.collab.net/
    Mark

  6. Adam says:

    Thankyou for this concise post on the subject. At my workplace, we are just making the jump from Sourcesafe to SVN and have been considering this very issue. The other main consideration that applies to our decision is that we have a structure to our list of projects, which fall into three basic categories. We could re-create this structure in a single repository, but not easily with separate repositories.
    Very interesting.
    Adam.

  7. ken says:

    I have installed and configured a subversion server with one repository but few projects, for example, 4 projects, A,B,C and D, if staff A commit a file which is under revision 30, staff B commit another file, the revision with continue to revision 31, if we need to separate project using separate revision db, so please teach me to how can i make it with only using 1 repository?
    Thanks & best regards,
    Ken

  8. Bob Kavanagh says:

    I have coded a main->sub repository and then coded for a separate repository for my program. How can I delete the sub-repository from the Main repository file

Leave a Reply

Your email address will not be published. Required fields are marked *

*