Teamwork Projects

Question

In our current project, we have four different TFS2010 team projects in the same Team Project assembly. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).

All projects now use the same template. Therefore, we came to the conclusion that it would be better to combine projects into a single team project. This raises several questions:

• Is it possible / possible to use one of the existing projects as a target project for the other three?
• How do we move our existing work items to a new project while maintaining our area tree? We hope to create one root area for each of our existing team projects and move all work items / areas under this root node.
• Today we have links to a work item from one project team to another - how do we save these links when merging?
• What is the best practice when moving source code? One simple approach is to simply copy it to a new location and lock and save the old team projects if we need to access older versions of the code. But is it possible to use branching for this, for example. fork all existing code into a new team project? What problems can this approach cause?

Thank you for your help!

Answer 1

Unfortunately, TFS 2010 does not allow team projects to be combined.

Structuring collective projects and collective project collections is one of the most important strategic decisions that must be made before using TFS. Unfortunately, many of the clients we help do not make advance planning necessary and do not understand some of the limitations in TFS around merging, moving, splitting, etc. Team projects before they begin to dive into the use of TFS :(

When we have consulting obligations, when clients want to consolidate their team projects, we are ultimately forced to do the manual work of transferring artifacts. We have created some tools that will help us in this process for work, but for the most part this is a lot of tedious consulting work. Migration utilities always need to be configured for each client, as they usually have different business rules for how they want to migrate.

Ultimately, “migration” does not translate all the information, and you end up with some other problems, such as date and time stamps, that are different from what they were originally from. (I heard this was referred to as a temporary compression issue with migrations.)

Some additional thoughts on each of your original questions:

• Of course, theoretically, you could use one of the existing team projects as a goal for moving the other three. For now, you like the name of the team project and don’t want to rename the team project . :)
• Here we created our own work item migration utilities to help our consulting clients. You may have to do the same.
• This is also possible with the custom work item migration utility. You can simply track the mappings between old work item identifiers and new work item identifiers, and then add links later when all new work items are created in the target team project.
• It is ultimately up to you. I would perform a “move” source control versioning operation from the old team project to the new team project. It supports everything. However, I would not delete any of the old team projects, because this would also destroy the history of version control.

This is not a good story for you, but hopefully it helps you with your planning!