SVN Project(s) organization: per-module or per-project

Question

I have a subversion repository that contains a number so subfolders, corresponding to the various applications, configuration files, DLLs, etc (I'll call them 'modules') that make up my project. Now we are starting to "branch" into several related projects. That is, each high-level project will use a number of the modules, possibly slightly modified from project to project. The number of projects is smaller (~5) than the number of modules (~20)

Now I'm trying to figure out how to organize the repo. Does it make sense to keep the top level subfolders on a module-by-module basis, with sub-subfolders for each project? Or should the top level be for each project, with each project having its own module subfolders:

repo:

module 1
    Project 1
    Project 2
    ...

    Project 5
module 2
    Project 1
    ....
    Project 5
....
module 20
    Project 1
    ...
    Project 5

-or-

repo:

Project 1
   module 1
   module 2
   ...
   module 20
Project 2
   module 1
   module 2
   ...
   module 20
...
Project 5
   module 1
   module 2
   ...
   module 20

Answer 1

I think that your use of "high-level" to describe what a project is suggests that you should have a Projects/modules setup.

However you could have a Modules and Projects set up - i.e., they are at the same level in the SVN repo. Your Projects can rely on Modules, and if possible the Projects can provide specific implementations of actions, turning the module into a base module with default but overrideable implementations.

Answer 2

I would organize by Projects THEN by modules (your second example) . The main reason why is because there is more overhead in managing a project, at least for me, than managing modules.

Each different project needs its own build script setup, properties file, etc. and it is a lot easier to keep track of 5 working copies on your computer than 20.

Answer 3

I prefer the 1st one.

While it does take extra effort per repository to maintain, I like my revision numbers to make sense for the project.

i.e. our flagship product has a revision of 48123, our new project has a revision of 31. If you have inter-repository dependencies, then you can use svn externals.

Answer 4

It would seem best to organize by Project at the top level, since you're going to want to checkout an entire branch and have a working copy for the project. If you organize by module, you'll have to do multiple checkouts (one for each module you're using) in order to build your project to a point where it's useable.

It could make sense to keep both projects and modules separate, E.g.:

Projects
   Project 1
   Project 2
   ...
Modules
   Module 1
   Module 2
   ...

If you use that in combination with svn externals and/or vendor branches, you could support different branches for your projects that need different module versions, but still benefit from the having a single module source when projects happen to share the same version of a module.

Answer 5

I would tend to organize by project, but now always. If you have access control aspects of your code, then organize to minimize permissions-administration; this could also result in a per-team organization of the repository.

By the way: You seem to expect to work in one big repository - which I think is clever, because it means better history handling: As soon as you move stuff between repositories, you loose history. In other words, I disagree with Ben Scheirman's advice on this.