Subversion project structure?

Question

When creating projects for subversion should each individual project contain its own trunk, branches and tags directories? eg.

MyProject 1
- branches
- tags
- trunk
MyProject 2
- branches
- tags
- trunk
etc...

OR should each project itself go inside an all-encompassing structure? eg.

branches
tags
trunk
- MyProject 1
- MyProject 2
etc...

Answer 1

Option 1 would be a lot simpler to split in to a different form of source control should the need arise, and is therefore what I would prefer.

It also seems to me that it would be easier to manage project-wide permissions in the first option.

Answer 2

Both approaches are common, although the first option is more common.

Even more common is to set up separate repositories for separate projects - people just can't stand the idea of having "unrelated" stuff in "their" repository.

Answer 3

With a recent CVS-to-SVN switch, we have decided for something in between: Group related projects together on top-level, with trunk/tags/branches underneath, and the projects underneath this.

This was done because, at this place, a lot of projects relate to each other and are often tagged, branched etc. together.

Answer 4

I personally go for option 1. This is because of the following fairly subtle problem with option 2:

With option2, it's common to have your working copy match the repository structure. This means that effectively you checkout the entire copy (or parts of it, but in the same general structure).

This is a problem when it comes to dependencies, say projectA & projectB references libraryC, there's no control between changes made in the library and the changes being applied to the 2 projects. As soon as a commit is made to the trunk of libraryC, it's picked up by all projects that use it. The net effect of this is that you get scared to change libraryC because it may break one of the projects.

With option1, you can use externals to bring in a specific version of libraryC into projectA & projectB. In fact, A & B can use different versions, if needed.

This means you can change libraryC at will, then control when the change gets applied to the projects - testing and changing code as necessary and knowing that you're upgrading to the latest version of the library. If there's a fundamental problem with the upgrade, you can keep using the old version until the problem with the library is fixed.

Another way to look at this is that with option2, if you look at the history for projectA, you can't tell when changes made to the library affected the project. In fact, the same revision of projectA may work one day and not the next, because the library was changed. The only way you can get a history which tell you the changes is to look at the full history, which will also include completely unrelated changes for projectF and libraryX, making the useful information you're after hard to see.

With option1, there's a revision in the history of projectA telling it to use the new version of the library. The change doesn't happen magically - it when you explicitly say to use the new version of the library. This is generally a much more stable environment.