Is a good idea to put all projects in the same trunk?

Question

We understand the default and usually recommended svn repository organization, in case of having multiple projects, is something like this:

root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...

Our projects have a lot of interdependence, and that would demand an extense use of svn:externals between them, considering we don't do dll referencing to internal projects, we'd prefer to view their source code instead of working with binaries.

Using externals too much, when branching repositores, syncing changes, can become a complex and error-prone experience, so the team didn't trust this solution at all.

So a team member suggested something that we all think this could be a better solution: put all projects in the same trunk.

At first, we recognized some problems with this approach, but as a whole we agree these problems are based on hypotethical situations that very probably we'd never experience.

Do you see some serious problems we may have with this solution?

Answer 1

We do this at our company and have had a lot of success.

We have 3 top level directories:

• tags
• branches
• trunk

And then we have each project as a sub-directory of those.

We still branch at the project level though and still use svn:externals. But if we had a smaller source tree we would branch at the trunk level and not use svn:extenrals.

It's nice to be able to have all projects' trunk at the same place. You can back it up, you can check it all out and you have all the most recent stuff together. You don't lose the single location for all branches nor single location for all tags either because they are all in subdirectories of /branches/projectX and /tags/projectX

Problems with svn:externals:

If your projects are not extermely HUGE then you could just branch the whole trunk each time and avoid all of the problems with svn:externals.

The problem with svn:externals is that when you make a branch, it doesn't automatically create a branch for each of the svn:externals for you. This is a problem because then over time all of your old branches won't be able to compile as your trunk gets more updated. Another problem is that if you make a fix in any branch to an svn:external, all your other branches break.

Another problem with svn externals is that when you do an svn:log at the root level, you don't see any changes from svn externals.

Hopefully one day svn externals will be fixed to address the above problems, but until that day branching and svn:externals is an absolute nightmare.

Answer 2

What you've done is what I've set up at my company, and it is also referenced as a "very common layout" in the svnbook topic, Strategies for Repository Deployment.

Nothing wrong with it.

Answer 3

Hi,

to "putting all projects into same trunk":

From my experience this is no good idea - because each project has it's own history and changes and often projects are/will be maintained by different developers. This can lead to conflicts - even if you state out, that currently the projects interfere heavily.

So why don't you use common tags (with milestones as names to) for all of your projects to ensure a same code base and a build script, which can check out the projects (trunks) automagically? It's more work, but like usual in OOP (capsulation) I would prefer to split the projects into separate SVN directories, too.

But: Collecting a bunch of small libs and apps into a common directory under the same trunk is no problem (see "apps" and "tools" in my example below) - so maybe "small projects" can stay in the shared/big trunk.

Here as example my directory structure of SVN:

/projects/
/projects/CustomerA/
/projects/CustomerA/ProjectX/
/projects/CustomerA/ProjectX/trunk/
/projects/CustomerA/ProjectX/tags/
/projects/CustomerA/ProjectX/branches/
/thirdparty/
/thirdparty/ExtLibY/
/thirdparty/ExtLibZ/
/tools/
/tools/trunk/
/tools/tags/
/tools/branches/
/apps/
/apps/trunk/
/apps/tags/
/apps/branches/

So all of the external stuff is stored in /thirdparty/ and all internals (projects, tools, apps) have the subdirs:

/trunk/
/tags/    
/branches/

...like advised in the Subversion book and the previous post.

Even if that looks a little bit much efforts at first sight - it is really worth it, especially when your code base grows.

ciao, Chris

Answer 4

Do you see some serious problems we may have with this solution?

• Your solution only works as long as you can put everything in a single repository.

  This means the entire repository has to fit on a single disk (or storage pool) for the foreseeable future. Similar considerations apply for other server resources like network and disk I/O bandwidth.

  Splitting the repository later will require a big overhaul of your whole set-up, and might cause headaches when you need to rebuild or branch old versions.

• Your solution only works if you don't need to limit read/write permissions on a per-user basis

  If you need to give read/write permission for projectA, you'll actually have to give permission for /trunk/projectA, and /branch1/projectA, and /branch2/projectA etc.

  Branching then becomes a heavy-weight process that requires lots of permission tweaking. Say goodbye to feature branches.