I’m new to TFS (and branch/merge style source control). I’ve been reading through the TFS Branching Guide for 2010, but I’m having a bit of a disconnect with how my solutions should be mapped to the source control. I think my main problem is how to understand th best placement of class libraries shared between solutions.
Our environment is line-of-business with about a dozen separate web applications and about half a dozen class libraries shared between the web applications. Our solutions generally consist of one of the web applications, it’s unit testing project, the supporting class library projects, and any third-party assembly references.
So two representative solutions would look like:
SOLUTION A
— WebApp11 Project
— WebApp11UnitTests Project
— ClassLib11 Project
— ClassLib22 Project
— ClassLib33 Project
— bin\*.dll
SOLUTION B
— WebApp22 Project
— WebApp22UnitTests Project
— ClassLib11 Project
— ClassLib22 Project
— ClassLib44 Project
— ClassLib55 Project
— bin\*.dll
How should these be structured in TFS?
Do we create a Team Project for each Solution, such that ClassLib11, for example, would belong to both TEAM SOLUTION A and TEAM SOLUTION B?
I’m thinking yes, so that each Team Project consists of everything required to roll out into production.
What if we use a couple different solution files, such as having one large solution file that has every web application and every class library? Where does that solution fit in?
We keep all of our production applications (we have a suite of applications that have significant overlap) in a single TFS Project. This allows all of them to be governed by the same rules since they are, potentially, all being modified by different people all the time but a single person will sometimes/often have scenarios where they are interested in many different applications together.