What is the best branching strategy in TFS to share code between multiple team projects?

Question

This is a theoretical question about branching, not about code architecture or layers.

I have a Team Project "SuperLibs" with 25 .NET projects (which are class libraries). Team Project's structure is such:

• Main (current stable version under development)
• Dev (branched from Main - unstable code under development)
• Releases\Release 1.0
• Releases\Release 2.0
• Releases\etc...

And I have another Team Project "SuperLogic", which contains a logic for application and depends only on 5 projects from SuperLibs. Team Project's structure is such:

• Main (current stable version under development)
• Dev (branched from Main - unstable code under development)
• Shared\SuperLibs\Release 1.0 (branched from Release 1.0 of SuperLibs)
• Shared\SuperLibs\Release 2.0 (branched from Release 2.0 of SuperLibs)
• Releases\Release 1.0
• Releases\Release 2.0
• Releases\etc...

And finally I have third Team Project "SuperApp" which depends both on "SuperLibs" and on "SuperLogic". Team Project's structure is such:

• Main (current stable version under development)
• Dev (branched from Main - unstable code under development)
• Shared\SuperLibs\Release 1.0 (branched from Release 1.0 of SuperLibs)
• Shared\SuperLibs\Release 2.0 (branched from Release 2.0 of SuperLibs)
• Shared\SuperLogic\Release 1.0 (branched from Release 1.0 of SuperLogic)
• Shared\SuperLogic\Release 2.0 (branched from Release 2.0 of SuperLogic)
• Releases\Release 1.0
• Releases\Release 2.0
• Releases\etc...

No binary references used. Only project references are used.

Now here is the situation:

• When I build "SuperLibs" - everything is ok
• When I build "SuperLogic" - everything is still ok, because SuperLogic is referencing SuperLibs' projects in folder "Shared\SuperLibs\Release x.y"
• But when I try to build "SuperApp" - it fails, because it is able to reference SuperLogic and SuperLibs inside "Shared" folder, but "SuperLogic" in "Shared" folder cannot reference "SuperLibs".

While I have no wish to play around with referenced paths of branched projects, maybe someone has experience with similar projects branching or can offer better branching strategy?

Answer 1

I'd just remove branching from the equation entirely. You're branching these three things separately, which means you're versioning them separately. If you're versioning them separately, turn everything into NuGet packages and reference the binaries via NuGet.