TFS Best practice for team projects

TFS Best practice for team projects

TFS Best practice for team projects

I work in a small software house and have been asked to produce a migration path between VSS2005 and TFS2008 (using VS2008 Team Explorer). I have managed to get most of the work done, but I have hit a bit of a roadblock concerning team projects.

Basically I have in the region of 200 top-level projects that I need to migrate. Of these quite a lot can be moved into related groups, for example Project1 might have the following

This would obviously reduce the need from 4 team projects to only 1. However there seems to be a load of conflicting information on whether this is the best way to do it. I'd appreciate it if any TFS experts could advise on the following:

1) Is this a good/practical way to do it?2) If I do it this way can I ensure complete independence between the sub-projects - although they are linked in terms of a business solution we will never need to release them as a joint build, i.e. some files relate to console apps that are scheduled reguarly, some are winform apps etc. I was intending to include the sln files in, for example $Project1/App1.3) Will the revision history work ok using this method?

RE: TFS Best practice for team projects

I've done further investigation and it would appear that the way I suggested initially is the only way I can do it in TFS2008. In TFS2010 there is the ability to have Team Project collections which allows you to have repositories that are completely separate, but it still wouldn't have matched what I needed.

As an additional requirement I have had to split further into Production and Development repositories, so I have ended up with a structure like this:

This would have allowed me to create a team project for each distinct project, which would have been far better but I am having to use TFS2008 so not a lot I can do. On the plus side I have tested it and it seems to work....