Folder structure for many projects in one SVN repository?

Question

I just created a Google Code SVN repository for storing my school projects and homework, and to allow easy transferring between school and home.

Its default directories it creates are:

https://simucal-projects.googlecode.com/svn/trunk/
https://simucal-projects.googlecode.com/svn/tags/
https://simucal-projects.googlecode.com/svn/branches/

I've never used a repository for more than one project, but after reading: One svn repository or many? I've decided to have a single repository for all of my random school projects.

Should I just replicate the folder structure above, but for each project?

https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/

https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/

Is this what you multi-project-in-one-repo people do?

Answer 1

That's what I use for my home source control.

Where I only have one primary repository.

Repository/Project1/Trunk
Repository/Project1/Tags
Repository/Project1/Branches

Repository/Project2/Trunk
Repository/Project2/Tags
Repository/Project2/Branches

I like this structure, it's very easy to reference projects and maintain integrity.

Answer 2

There is no clear answer to this question as it depends on what suits your projects best.

1. I would use /projectA/trunk layout if there was either a heavy development going on per project and everything needs to be separated since there is not that much connection between it (components/projects that stand alone). However, you could also use one SVN repository per project then. Remember you won't be able to check out all projects using svn co http://..../svn/ because this would also fetch all tags and branches from all projects, not only trunk.
2. /trunk/projectA would certainly be better if your projects/components belong tightly together and you need to tag and branch them from the same revision (like a library belonging very closely to the main project). You can also use svn co http://.../svn/trunk/ to get all projects on their latest trunk revision if you like.

From a maintainability point of view I would almost always prefer the second way; but if your projects get bigger and might prolong, it would be better to use separate repositories per project.

Besides that: Please check if you really need Google Code services for your homework because its purpose is to support OSS. You can always use SVN locally or even through SSH, so you could also put your repositories on an USB stick or some computer that can be accessed remotely; you don't really need hosting for that. There could also be privacy concerns.

Answer 3

You have two options for this. The one you already mentioned, and that is to have a trunk for each project (option 1):

https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/

https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/

Option 2 would be to have one trunk with each project being a subfolder under trunk:

https://simucal-projects.googlecode.com/svn/trunk/projectA/
https://simucal-projects.googlecode.com/svn/tags/projectA/
https://simucal-projects.googlecode.com/svn/branches/projectA/

https://simucal-projects.googlecode.com/svn/trunk/projectB/
https://simucal-projects.googlecode.com/svn/tags/projectB/
https://simucal-projects.googlecode.com/svn/branches/projectB/

The advantage of option 1 is that you can branch and tag each project independently. This is desirable if you need to deploy each project seperately.

Option 2 is desirable if all the projects are deployed together. This is because you only have to tag the repository once when deploying.

Since you are using Subversion for school projects, you need to ask yourself whether you will ever need to tag your work. You can also ask yourself whether you ever need to create branches (you probably would want to if you want to experiment a bit). You will also need to ask yourself whether you are happy to branch ALL your work together as one, of whether you prefer the flexibility of branching each project independently.

The rule of thumb that I always follow: trunk together whatever we deploy together.

(By the way - you can have many trunks in the same repository - this is almost equivalent to having one trunk in multiple repositories, except that each repository maintains its own revision counter and you cannot merge between repositories.)

Answer 4

If you insist on having just one repository (I'm in the DON'T camp myself) and do branching then I think what you propose is good. But again, I consider a SVN repository is equal to a project.

Answer 5

A real-life example: The Apache Projects repository.

Answer 6

For java project developed in Eclipse I'd choose a structure which is completely flat and shallow from the root:

/trunk
  project1
    ...
    .project
  project2
    ...
    .project
  third-party1
    *.jar
    .project
  log4j.v-bla-bla
    *.jar
    .project
  log4j.v-bla-bla2
    *.jar
    .project

The main reason is (or was at least for Eclipse 3.X) that there is no way to have nested projects. The java wizardry in Eclipse will always force you to have a project per buildable jar, project per group of 3rd party jars with /without source code, project per deployable war/ear etc. To proove that your Eclipse projects dependencies are correct try to build one main project and see if build is incremental and is affected my changes in other projects providing the dependencies.