Team Development with Visual Studio Team Foundation Server

Figure 10.2 Multiple Solution Approach
In this scenario, all references inside each solution are project references. References to
projects outside of each solution (for example to third-party libraries or projects in
another sub-solution) are file references. This means that there can be no “master”
solution. Instead, you must use a script that understands the order in which the solutions
must be built.
One of the maintenance tasks associated with a multiple-solution structure is ensuring
that developers do not inadvertently create circular references between solutions. This
structure requires complex build scripts and explicit mapping of dependency
relationships. In this structure it is not possible to build the application in its entirety
within Visual Studio. Instead, you use TFS Team Build.
For more information about this multiple solution approach, see “Chapter 3 - Structuring
Projects and Solutions in Source Control.”
Branching and Merging Considerations
Large teams are likely to branch both by team and by feature and are also more likely to
have one or more branches designed to integrate external dependencies. Since the
branching structure is deeper, there is more lag between a change in a development
branch and getting that change into the main integration branch. For this reason it pays to
careful consider your merging strategy when creating branches.
For example, consider the following when deciding whether your merges will be
scheduled or event-driven:
• Reverse integration is generally scheduled, for example merging from a development
branch to the main integration branch.