There are a couple ways to approach structuring your Team Projects depending on what you want to accomplish (see the answer to the “Should I create a team project per application or per release?” in the FAQ). Consider the per application scenario, where you have a single Team Project with multiple trunks per-version:
|- Version 1.1
|- Version 1.2
|- ... etc ...
A Team Build, by default, will apply the build label at the Team Project level (in this case $/My Project). Then, in order to gather changeset and work item details for the build report, it looks at the history of everything that has been given that label. Well, as you can imagine, this is a bit of a problem if there is concurrent development being done in the Version 1.1 and 1.2 branches since a build of one will label and gather changesets for the other.
We realized this problem today as we started a new version branch and, initially, we weren’t sure if we’d be able to prevent it. Then I dug around in the team build files for about five minutes looking for a way to control this and found a solution that might work, but was reluctant to change the Team Foundation MSBuild file since I don’t want to have to support changes to that on multiple build machines, dev workstations that do desktop builds, etc. So I did a search real quick and, what do you know, there is a way to fix this by only having to modify the build type’s proj file. It has to do with changing where the label is applied. Instead of applying it to the Team Project level, you can actually have it apply the label to a specific subdirectory and then the report will only reflect the changes to that subdirectory. You can get the details on how to achieve this behavior with Team Build over on Manish Agarwal’s blog.