Subversion Repository Layout

Question

Most subversion tools create a default repository layout with /trunk, /branches and /tags. The documentation also recommends not using separate repositories for each project, so that code can be more easily shared.

Following that advice has led to me having a repository with the following layout:

/trunk
      /Project1
      /Project2
/branches
         /Project1
         /Project2
/tags
     /Project1
     /Project2

and so on, you get the idea. Over time, I've found this structure a bit clumsy and it occurred to me that there's an alternative interpretation of the recommendations, such as:

/Project1
         /trunk
         /branches
         /tags
/Project2
         /trunk
         /branches
         /tags       

So, which layout do people use, and why? Or - is there another way to do things that I've completely missed?

Answer 1

I find that the Subversion Repository Layout blog post summarizes this pretty well:

(...) there are several common layouts that have been adopted by the community as best practices and therefore one could think of these as recommendations. If your repository is accessible to the public, following these conventions might make it easier for users that have accessed other Subversion repositories to find what they are looking for.

There are two commonly used layouts:

trunk
branches
tags

This first layout is the best option for a repository that contains a single project or a set of projects that are tightly related to each other. This layout is useful because it is simple to branch or tag the entire project or a set of projects with a single command:

svn copy url://repos/trunk url://repos/tags/tagname -m "Create tagname"

This is probably the most commonly used repository layout and is used by many open source projects, like Subversion itself and Subclipse. This is the layout that most hosting sites like Tigris.org, SourceForge.net and Google Code follow as each project at these sites is given its own repository.

The next layout is the best option for a repository that contains unrelated or loosely related projects.

ProjectA
   trunk
   branches
   tags
ProjectB
   trunk
   branches
   tags

In this layout, each project receives a top-level folder and then the trunk/branches/tags folders are created beneath it. This is really the same layout as the first layout, it is just that instead of putting each project in its own repository, they are all in a single repository. The Apache Software Foundation uses this layout for their repository which contains all of their projects in one single repository.

With this layout, each project has its own branches and tags and it is easy to create them for the files in that project using one command, similar to the one previously shown:

svn copy url://repos/ProjectA/trunk url://repos/ProjectA/tags/tagname -m "Create tagname"

What you cannot easily do in this layout is create a branch or tag that contains files from both ProjectA and ProjectB. You can still do it, but it requires multiple commands and you also have to decide if you are going to make a special folder for the branches and tags that involve multiple projects. If you are going to need to do this a lot, you might want to consider the first layout.

So, to paraphrase:

• Use the first layout for a single or multiple related projects.
• Use the second layout for non related projects.

The whole post is worth the read.

Answer 2

The second layout is the way to go. One good reason is to allow or deny a developer to work with one of the projects.

Answer 3

I prefer the second. With the second, if people's permissions are different between the two projects, it's easier to implement.

Answer 4

I greatly prefer the second, using maven or ant/ivy to ingest the artifacts from other projects if needed.

I also prefer to have a single project per repository, or a small number of related repositories.

It simplifies access control, which is easier at the repository level than the path level within the repository - particularly when authenticating against LDAP.

Backup/restore operations are a little more complicated initially as you have to loop through all the repositories to do a hot copy, but in the unlucky event you have to restore only one repo - the others needn't be taken offline or loose any data. As projects die, the repositories can simply be deleted thus saving you space on future backups.

Hook scripts become simpler when there is only one project (or a small number of related projects) per repository, you don't have to examine the affected path to conditionally take action in your hook.

As retracile noted, one monolithic repository is likely going to be a huge pain if you ever want to selectively export using svndumpfilter - the number of changed paths causing it to die is likely to be high.

Upgrading the repository schema for future versions of svn requires more effort - you have to do it n times rather than once... but it can be scripted and you needn't coordinate everyone at once.

If someone commits a password, and you have to obliterate it, you can do the dump/filter/reload quickly in one repo while not affecting other teams.

One piece of advice if you go this route - have a different .conf file per repo rather than one huge one, again it's easier to manage as well as providing comfort that some timestamps are going to be old - if something's amiss you can look for recent changes easier.