Question

This is the SVN structure:

/trunk
    + ProjectA
    + ProjectB
    + Common
        + ProjectCore
        + References

ProjectA and ProjectB will deliver an end product and each can have their own release life cycle. Both projects make use of the same common libs from ProjectCore.
ProjectCore will also have its own release life cycle.
In ProjectA and ProjectB we want to refer to the libs of ProjectCore. The ProjectCore-libs were added to SVN after succesful release life cycle of ProjectCore. The ProjectCore-libs are added to the References folder.

By doing this we release (freeze) our ProjectCore builds, as a component which was fully tested. So we have multiple Core-lib releases:

• RLS_Core_1.00
• RLS_Core_1.01
• RLS_Core_2.00
• RLS_Core_3.00

Since we add the released libs (dll’s) to SVN, ProjectA and ProjectB can refer to them.
What is the best approach to do this?

Approach 1

Add the ProjectCore-libs to SVN in a new folder under References named RLS_Core_X_XX.

In the solution of ProjectAand ProjectB we add a reference to this unique folder: ./trunk/Common/References/RLS_Core_X_XX.

Approach 2

Add the ProjectCore-libs to SVN under one and the same folder References/Core. In case there was an “older” version in it it will be a commit.

In the solution of ProjectAand ProjectB we add a reference to: ./trunk/Common/References/Core. We use the SVN externals properties to define which revision of the Core-libs must be used for ProjectA and ProjectB.

In both approaches the developer explicitely needs to decide what Core-libs release he wants to use in his project soution. The rule is keep the same Core-libs unless you have to upgrade because of missing functionality.
Approach 1: edit in project solution. Approach 2: edit in externals properties.

What approach is preferred?

Answer 1

First thing which would seem natural is to use the recommended folder structure (branches, tags, trunk) folder for each project separately. That goes for the common project too, especially if you are going to have releases referenced by those two end products. Since these projects are going to be developed separately, you should be able to create individual tags and branches.

Once you’ve done this, (and since it’s your requirement to include all references as built assemblies) it would be a good idea be to copy released assemblies into each projects Reference subfolder separately.

This way, whenever you create a branch, you have the exact snapshot of the version you need, and it’s independent from the common stuff development.

In other words:

/RepoRoot
    + ProjectA
        + branches
        + tags
            + v1.0
            + v1.1
        + trunk
            + references (includes 3rd-party and ProjectCore)
    + ProjectB
        + branches
        + tags
            + v0.8
            + v1.2
        + trunk
            + references
    + ProjectCore
        + branches
        + tags
            + v2.0
            + v2.1
        + trunk
            + references