Svn organisation problem

Question

I'm not sure how to organise these projects since they all depend on each other.

Right now its all in the following structure, which is getting hard to manage

-trunk
 |-bin - compiled common dlls
 |-lib - static libs for use with common dlls
 |-src - common dll source code
 |-include - headers for common dlls
 |-common.sln - VS 2008 solutions for common dlls
 |-samples
 ||-res - resources for samples
 |||-img
 |||-snd
 ||-c++ - c++ samples for common dlls, tends to double up as tests
 |||-various VS 2008 sample solutions
 ||-py - python versions for some samples
 |||-...
 |-wrappers
  |-python
  ||-bin - compiled python extension dll
  ||-src - source for python wrapper
  -Apps - actaul programs using common dlls, each with its own dir and solution
  |-...

This has a number of problems: -1 the svn structure is just a bit of a mess, I have no real way to create a bracnh for just one application for example -Making releases for anything is a massive pain due to the file paths used by the app. Eg a python program needs to know where the python extension dll is, and where each of the common dlls is. These paths are very diffrent on svn from what they would be for a release (where they are all likly in a common dir)

Answer 1

In general if you have multiple projects within a subversion repository and its getting messy you want to do one of two things:
1) You merge it all into one monolithic project because everyone is working on the same thing and hence tags and branches apply to everything. This tends to be done where the same team is working on all of the code and the projects are really just components compiled differently.

2) You split the different projects apart, put them in their own repository (or at least split them at the top with their own trunk/branch/tag section underneath that project directory) and build them completely separately and publish them to repository, in this case a shared file system or web server.

In your specific case it all looks like you have two projects, a common set of library code and some users of this code. Thus you would end up with a top level structure of:

1. Apps
2. Common
3. Samples (Maybe?!)
4. Wrappers

Each of which would have its own trunk, tags, branch structure underneath that project directory. each of them also has a copy of the compiled binary which represents the output of the dependent projects (or refers to the version in the repository) and you thus have a formal way of moving forward on dependencies.

Answer 2

Eurrghh!

Divide everything into separate projects/dlls/libraries/artefacts - whatever you want to call them and follow the recommended SVN structure:

/ (root)
  /Application1
    /branch
    /tag
    /trunk
  /Application2
    /branch
    /tag
    /trunk
  /LibraryX
    /branch
    /tag
    /trunk
  /LibraryY
    /branch
    /tag
    /trunk

Then where an application expects one of those libraries or dependencies to be in a directory within it's structure, use the svn:external property to pull it in.

For example, if you wanted the compiled dll from LibraryX to be in a folder called dll within Application1 then you would need to add the following svn:external property in your repository at /Application1/ :

svn://repositoryname/LibraryX/buildoutput/ dll

When you checkout Application1, you would get all its files plus it would add a folder called dll within your working copy that would be checked out from LibraryX/buildoutput/

You can also check out each project into it's own folder and cherry-pick certain files. But this requires a slightly different approach - you would have folders all with the same parent folder on your local machine checked out like this:

Application1 (checked out from svn://repositoryname/Application1/trunk)
LibraryX (checked out from svn://repositoryname/LibraryX/tag/stable)

So then if you wanted a specific file from the build output of LibraryX, you would add:

svn:externals ../LibraryX/build/thelibfile.dll libfile.dll

..as a property to the checked-out working copy of Application1 and it would pull in the libfile.dll from LibraryX and stick it in the root of your Application1 working directory.

Note, a major benefit of this is that by using tags, you can have your applications pull in specifically tagged versions of its dependencies. In the above example, a developer can work on Application1's trunk but using a stable version of libraries. When the next stable release of the library is created by re-tagging, simply update and it'll get plonked onto all your developers' machines within their development working copies.

Externals only work for single files when you have them checked out and referenced from local working copies, you can't do it direct from the repository like you can with folders .. yet.

You can only bring in single file externals with subversion version 1.6.x