Handling relations between multiple subversion projects

Question

In my company we are using one SVN repository to hold our C++ code. The code base is composed from a common part (infrastructure and applications), and client projects (developed as plugins).

The repository layout looks like this:

• Infrastructure
• App1
• App2
• App3
• project-for-client-1
  • App1-plugin
  • App2-plugin
  • Configuration
• project-for-client-2
  • App1-plugin
  • App2-plugin
  • Configuration

A typical release for a client project includes the project data and every project that is used by it (e.g. Infrastructure).

The actual layout of each directory is -

• Infrastructure
  • branches
  • tags
  • trunk
• project-for-client-2
  • branches
  • tags
  • trunk

And the same goes for the rest of the projects.

We have several problems with the layout above:

1. It's hard to start a fresh development environment for a client project, since one has to checkout all of the involved projects (for example: Infrastructure, App1, App2, project-for-client-1).
2. It's hard to tag a release in a client projects, for the same reason as above.
3. In case a client project needs to change some common code (e.g. Infrastructure), we sometimes use a branch. It's hard to keep track which branches are used in projects.

Is there any way in SVN to solve any of the above? I thought of using svn:externals in the client projects, but after reading this post I understand it might not be right choice.

Answer 1

You could handle this with svn:externals. This is the url to a spot in an svn repo This lets you pull in parts of a different repository (or the same one). One way to use this is under project-for-client2, you add an svn:externals link to the branch of infrastructure you need, the branch of app1 you need, etc. So when you check out project-for-client2, you get all of the correct pieces.

The svn:externals links are versioned along with everything else, so as project-for-client1 get tagged, branched, and updated the correct external branches will always get pulled in.

Answer 2

A suggestion is to change directory layout from

• Infrastructure
  • branches
  • tags
  • trunk
• project-for-client-1
  • branches
  • tags
  • trunk
• project-for-client-2
  • branches
  • tags
  • trunk

to

• branches
  • feature-1
    • Infrastructure
    • project-for-client-1
    • project-for-client-2
• tags
• trunk
  • Infrastructure
  • project-for-client-1
  • project-for-client-2

There are some problems with this layout too. Branches become massive, but at least it's easier to tag specific places in your code.

To work with the code, one would simply checkout the trunk and work with that. Then you don't need the scripts that check out all the different projects. They just refer to Infrastructure with "../Infrastructure". Another problem with this layout is that you need to checkout several copies if you want to work on projects completely independently. Otherwise a change in Infrastructure for one project might cause another project not to compile until that is updated too.

This might make releases a little more cumbersome too, and separating the code for different projects.