We started with a similar model, but found it to be a bit cumbersome. The main problem is that if you want to branch your codebase at a release, you have to go make branches for each component.

Instead, we ve considered a scheme like the following:

  trunk
    app1
    app2
    lib1
    lib2
  branches
    rc-2.0
      app1, app2, lib1, lib2...
    some-devs-branch
      app1, lib2
  tags
    release-1.0
      app1, app2, lib1, lib2...

I like having a separate repo entirely for 3rd-party stuff. Unless you plan to implement the full vendor-branching strategy from the red bean book, this will work well.

We ve been strugling with this too.

We ve found out that it doesn t take long until some shared libraries are part of multiple applications and you would want to have everything on the same version. Therefore we ve decided to put everything we do in one single repostitory. We ve been working this way for over 2 years now and find it very good to work with.

All configurations have pro s and con s but by having 1 full repository you can be (almost) sure that you have all files together at the right version. If you work with multiple trunk s there are tricks with virtual folders or links (I ve forgotten the term) to make it link with each other, but getting back to the point where you were is very hard.

Just remember each config has pro s and con s, but for a not to large company I would suggest to put everything in a single repo with one parent folder.

My current approach is breaking the systems on logical application boundaries all under one repository.

For example, imagine a service that also has a test suite and a database

/project1/application1/
                      trunk/
                            Src
                            Test
                            Database
                      tags/
                      branches/
         application2/
                      trunk/
                            Src
                            Test
                      tags/
                      branches/                       

This Allows us to have multiple applications assoicated with a project, but handle release control for each "logical" application boundary. Consider where/what your release control need are and set those as the location of the branch/tag/trunk structure.

I don t like the single trunk/branches/tags folder at the root of the entire repository, because I don t want to have the entire trunk checked out, nor do I want to mess with partial branch checkouts as a result. (You may disagree and your mileage may vary etc etc)

SVN provides tags to take a snapshot in time of the source tree at a particular time (which you can use for releases, etc.).

But if you re intending to make your repository more granulated , maybe you should consider setting up multiple repositories.

Of course, within the trunk folder, you should set up whatever normal directory hierarchy you would if you didn t use source-code control.

We always create a separate SVN repository for each separate "solution". This repository then just has a simple trunk, branches and tags structure.

Any dependent frameworks (where we control source code) then have their own separate repository. We typically then just include binaries (at a particular version) into any project using them.

Having a single repo for everything means that you have a pretty good chance of ending up with a huge repository pretty fast. Which means things can get slow and a bit hard to track as well. Obviously, it depends on your exact use case, but personally I d opt for per-project repositories and using svn:externals where needed.

Actually, I d opt for a distributed VCS over SVN if possible, but to each his own...