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:
- 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).
- It’s hard to tag a release in a client projects, for the same reason as above.
- 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.
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.