I don't necessarily agree (nor do I necessarily agree with Martin and the other referenced sources) with respect to the basic approach for organizing Team Projects.
The VS ALM Ranger team recently published an MSDN article on Team Project Collections and Team Projects (http://msdn.microsoft.com/en-us/magazine/gg983486.aspx). In this article, we tried
to describe various considerations for deciding when (or wnen not) to combine Visual Studio Projects / Solutions into a single Team Project vs organizing them into separate Team Projects. As Zephan indicated ealier, each Team Project has its own Process
Template. So if you had two project teams, and one wanted to use the MSF for Agile Development v5.0 process template while the second team wanted to use the MSF for CMMI Process Improvement v5.0 process template, then they would each have to be working in
their own Team Project.
Likewise, if you wanted a different security model (where the tech lead of one team with branching permissions in his / her own team project, should not be permitted to branch the code for the second team project, or where developers on one team
are only able to check code into branches in their own team project and not into branches in the second team's team project) - then isolating these two teams into separate team projects might be the answer.
I generally prefer to think of Project Intitiatives (a project with a set of requirements, a plan, a team, a set of milestones, a release schedule, etc that is different from another project iniative in my organization). I like to organize my Project
Initiative into its own Team Project. This offers the advantage that the project team has control over choice of process template, process template customization, work item / work flow customization, report and query customization - and does not need to reach
consensus with other proejct teams on these decisions).
Within the Team Project, I tend to like having a single branching strategy for the project initiative that takes into account how the team develops software (waterfall, iterative, agile, Scrum,etc). As well the branching strategy should take into account
how the team releases and supports software (do they release once every two years, do require sustained engineering - hot fixes and service packs for one or more production releases, do they have four-week sprints, do they have iterative releases. How many
parallel releases do they support. How many service packs per release, etc). When it comes to archiving a the code for a Project Initiative - it is easier to achieve when that Project Initiative has its own Team Project. It is very hard to archive *part* of
a Team Project.
I generally perfer to use the Areas feature of a Team Project for categorizing or organzing the code within my solution - rather than using it to organize multiple teams and solutions which could be in separate Team Projects but we decided to colocate them
within the same Team Project. So although you CAN have multiple Teams working within the same Team Project, and you can use Areas to organize them, I generally don't like this approach. When I want to isolate two teams I like to use Team Projects as my isolation
Having said that, if you like the concept of project of projects and the ease of reporting that you can achieve when everything is contained in one Team Project, by all means follow the suggestions in Martin's two blogs.
It is possible to query and report across Team Projects. It is also possible to branch across Team Projects (for example having shared code in one Team Project and then sharing that code to multiple other Team Projects - leverages the ability to branch across
Team Project boundaries.
From the opposing view point :-)
VS ALM Ranger