How do you structure your SVN repository?

Question

What is better?

A:

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B:

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

What repository structure do you use and WHY?

Answer 1

This might help

Answer 2

We use A, because the other one didn't make sense to us. Note that a "project" with regard to SVN is not necessarily a single project, but may be several projects that belong together (i.e. what you would put into a Solution in Visual Studio). This way, you have anything related grouped together. All branches, tags and the trunk of a specific project. Makes perfect sense to me.

Grouping by branch/tag instead does not make sense to me, because the branches of different projects have nothing in common, except that they're all branches.

But in the end, people use both ways. Do what you like, but when you decided, try to stay with it :)

As an addition: We have separate repositories per customer, i.e. all projects for a customer are in the same repository. This way you can e.g. make backups of a single customer at once, or give the source code of anything the customer owns to him without fighting with SVN.

Answer 3

I would suggest an option C:

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

I prefer to keep separate projects in separate repositories. Using svn:externals makes it easy to manage code library projects that are shared among two or more application projects.

Answer 4

We use setting B. Beause it is easier to check out/tag multiple projects at once. In svn 1.5 it is possible via sparse checkout, but not a one-click operation. You want to use setting B, if some projects have hidden dependencies inbeetween.

Answer 5

The Repository Administration chapter of the SVN book includes a section on Planning Your Repository Organization outlining different strategies and their implication, particularly the implications of the repository layout on branching and merging.

Answer 6

We use

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

Which I'm starting to regret. It should be flatter. This would be better.

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

Why? Products (components, finished software) last forever. Projects come and go. Last year there's just one project team creating product QUUX. Next year, that team is dispersed and one or two people maintain QUUX. Next year, there will be two big QUUX expansion projects.

Given that timeline, should QUUX appear in three project repositories? No, QUUX is independent of any particular project. It is true that the projects do have work products (documents, backlogs, etc.) that are part of getting the work done, but aren't the actual goal of the work. Hence the "projectX" repositories for that material -- stuff that no one will care about after the project is done.

I worked on one product that had three teams. Big problem with coordination of work because each project managed it's repository independently. There were inter-team releases and inter-team coordination. At then end of the day, it was supposed to one piece of software. However, as you can guess, it was three pieces of software with weird overlaps and redundancy.

Answer 7

A simple tortoise tutorial on structuring your svn repo. Basically it's ALWAYS better to use a multiproject structure

http://www.deaddevssociety.com/2010/08/create-subversion-repository.html