Subversion project structure?

Question

When creating projects for subversive activity, does each individual project contain its own catalogs of connecting lines, branches and tags? eg.

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

OR should each project itself enter a comprehensive framework? eg.

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

Answer 1

Option 1 would be much easier to split into another form of version control, if necessary, and therefore I would prefer.

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

Answer 2

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

It is even more common to create separate repositories for individual projects - people simply cannot stand the idea of ​​having “unrelated” things in their “own” repository.

Answer 3

I personally go to option 1. This is due to the following rather subtle issue with option 2:

With parameter 2, usually your working copy matches the structure of the repository. This means that you are effectively checking the entire copy (or parts of it, but in the same general structure).

This is a problem when it comes to dependencies, for example, projectA and projectB refer to libraryC, there is no control between the changes made to the library and the changes applied to 2 projects. Once commit is done in the libraryC trunk, it is matched by all projects that use it. The net effect of this is that you are afraid to modify libraryC because it could break one of the projects.

With option 1, you can use external elements to add a specific version of libraryC to projectA and projectB. In fact, A and B can use different versions if necessary.

This means that you can change libraryC at your discretion, and then control when the change will be applied to projects - testing and changing the code as necessary and knowing that you are updating to the latest version of the library. If there is a fundamental problem with the upgrade, you can continue to use 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 cannot tell when the 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 has been modified. The only way to get a story that tells you about the changes is to look at the full story, which will also include completely unrelated changes for projectF and libraryX, making useful information that you then hard to see.

With option 1, there is a revision in the history of projectA, in which he is invited to use the new version of the library. Changes do not happen magically - this is when you explicitly say to use the new version of the library. This is usually a much more stable environment.

Answer 4

With the recent CVS-to-SVN switch, we decided something in between: projects related to the group at the top level, with connecting lines / tags / branches below and projects under it.

This was done because in this place many projects are related to each other and often labeled, branched, etc. together.