What is the right way to structure a large multi-application codebase in SVN

Question

We've currently got a single repo with codesion, http://John.svn.cvsdude.com, with a single SVN project http://John.svn.cvsdude.com/MyProject, which contains a few subdirs for individual Visual C++ solutions

This all started as one application and though we did split off separate library projects for future re-use, it's still all the same SVN project. Lets say we aim to have multiple applications with some overlap in libraries used, what's the right/best way to set this up in SVN? Of course one could just keep one SVN project and put app-projects and library-projects as sub-dirs, but it hardly seems right somehow.

Say we have App1, App2, App3 and LibraryA, LibraryB, LibraryC, LibraryD where these are all separate projects/solutions... how would you organise this under one (or more repos)? Is there a best-practice?

Answer 1

I would keep everything in one repository and put each project and library in separate root directory of repository (see Planning Your Repository Organization for details).

Keep in mind that repository structure do not have to be identical to project files structure on disk.

Also I would use svn-externals to share library directories (kept as separate root folders of repository) among various projects.

Answer 2

I would recommend the following layout, all in the same repository:

App1\
    trunk
    tags
    branches
App2\
    trunk
    tags
    branches
App3\
    trunk
    tags
    branches
LibraryA\
    trunk
    tags
    branches
LibraryB\
    trunk
    tags
    branches
LibraryC\
    trunk
    tags
    branches
LibraryD\
    trunk
    tags
    branches

Now, I am making a few assumptions about your release schedule. I am assuming that each application and library are released under different schedules. This is a worst-case scenario actually, but my scheme will allow this. Each application needs to have its dependencies pre-compiled and included in its directory in the repository. Here's how App1 would look, given that it has dependencies on Library B and C:

App1\
    trunk\
        deps\
            LibraryB, release 1.1
            LibraryC, release 4.3
    tags
    branches

This means that whenever you branch trunk you will get the necessary libraries along, which greatly simplifies things. Observe that it is the compiled binaries of the libraries, not their sources.

A branch of trunk will use the above versions, and since you're not allowed to modify them, any bugfixes will need to go into App1. Meanwhile, to use the new versions of LibB&C you can update their versions in trunk, when they are released by the libraries team. So, after some time, your repository might look like this:

App1\
     trunk\
         deps\
             LibraryB, release 1.3
             LibraryC, release 4.4
     tags\
         release-1.0\
             deps\
                 LibraryB, release 1.1
                 LibraryC, release 4.3
     branches\
         stable-2.0\
             deps\
                 LibraryB, release 1.2
                 LibraryC, release 4.2

Work in trunk is allowed to use the latest library releases. The release-1.0 is using fixed releases (oldest version here), while the stable branch is using the previous version of the libraries.

The above scheme is something I thought about a lot at my last employer, but never got around to implementing. To make it work you need to have a codebase that is split into applications/libraries and development can take place in parallel. That wasn't really the case for us. But it is a worth-while goal, I strongly believe.

Good luck!

P.S. I strongly recommend against svn:externals. They can make branch management a lot harder. For example, if an external changes and a branch is dependent upon it, you are under risk of messing up that branch (making it uncompilable for example).