If you come to #svn and ask about what layout to choose for a repository, you will most likely will get this answer:

How you setup your repository is really up to you. It’s a management question. See http://svnbook.red-bean.com/nightly/en/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout for a discussion on what the Subversion team thinks is best practice.

But in most cases that factoid doesnt answer all questions that pop up. You instantly get questions like:

  1. (#q1) “Do you store multiple projects in a repository?”
  2. (#q2) “How do you store multiple projects?”
  3. (#q3) “Why do i need those branches and trunk dir? i will never do such fancy stuff.”

It seems layouting your repository is not as easy as it seems. Anyway lets see what we can do here.

what is a repository?

A repository is basically a versioned filesystem. This point seems to confuse many CVS users. Branches, tags and your mainline tree are only subdirectories in this filesystem. Getting used to this idea is very important.

CVS people keep in mind there is not a different layer/axis for branches/tags. Those are only subdirs somewhere in your repos.

This should answer the 3rd question. Whenever you need a branch for just testing stuff you will curse yourself, that you did not layout your repository properly. Of course svn allows you to fix the problem with some “svn mkdir” and “svn move”. But that complicates the diff/merge into with old revisions. As you already have taken the time to read this howto. Do yourself a favor and stick to the common subdirs. We will put in some more details as the discussion continues.

One repository to rule them all

In many cases this is a good decision. It works really well. Even at large scale:

I suggest to keep related projects inside one repository. This solution has multiple advantages. First of all you have all related code in one place. Furthermore you can merge between the projects if needed. This would not be possible with svn. (svk doesnt count here;)

Another point you should take into account is access control. Until subversion 1.2 only the Apache2 based solution allowed us to use finegrained access control. As of version 1.3 svnserve has that feature too. If you have to use an older subversion binary and Apache2 is not an option either, you might be forced to use seperate repositories just for the sake of access control for different subprojects. But dont worry. Once you can upgrade you can easily fix that1.

Layouting the repository

Single project repos.

This is easy. I suggest following suggestions from the svn book

1 Assuming you have all repositories for projectA in /srv/svn/projectA and your new repos is /srv/svn/projectA-all: 

for repos in /srv/svn/projectA/* ; do
    REPOSNAME="$(basename $repos)" ;
    svn mkdir -m "- basedir for project $REPOSNAME" file:///srv/svn/projectA-all/$REPOSNAME ;
    svnadmin dump $repos | svnadmin load --parent-dir $REPOSNAME /srv/svn/projectA-all/ ;
done