Handling relations between multiple subversion projects
c++, repository, repository-design, svn
Solution
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.
Problem
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.