Team Development with Visual Studio Team Foundation Server

• If the shared dependency is clearly owned by a particular team, store it in that
team’s team project.
• If the shared dependency has no clear ownership, create a team project
specifically for the shared code.
2. Branch the dependency into your project.
Once you have stored the dependency, branch the shared source or binaries into your
project. Every time you perform a merge from shared to consuming project, you will
pick up the latest source. This allows you to pick up changes on a regular schedule
and to perform integration testing before impacting your main source tree.
Additional Resources
• For an introduction to branching and merging, see “Branching and Merging Primer”
at http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx
• For more information about branching, see “How to: Branch Files and Folders” at
http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx
• For more information about merging, see “How to: Merge Files and Folders” at
http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
• For additional descriptions of how to branch and merge in Visual Studio 2005, see
“Branching and Merging Team Foundation Source Control” at
http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx
Avoid Workspace Mapping to Support Cross-Project Dependencies
In general, you should avoid dependencies that cross team projects and try to have all the
related/dependent solutions/projects under the same team project. This reduces the need
for build script customization. If you have a dependency, use project references to define
it, or branch the dependency from a shared project into your project. You should avoid
file references because they are more difficult to manage. The exception is when the
dependent project is developed in parallel and you need real-time changes. In this case,
you can consider using workspace mapping. However, you can still use branching in this
case to create a buffer of isolation, if the dependent code is causing too many breaking
changes.
Additional Resources
• For more information about creating a workspace, see “How to: Create a Workspace”
at http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx
• For more information about editing a workspace, see “How to: Edit a Workspace” at
http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx
Create Workspace Mappings at the Team Project Root Level
For new team projects, map your team project root ($/MyTeamProject) to a folder with
the same name on your local drive; for example, C:\TeamProjects. Because mappings are
recursive, your entire local folder structure is created automatically and will be exactly
the same as the structure in source control.