Is the storing of multiple products under a single TFS project a bad idea?

We have Team Foundation Server 2008 deployed as our source control management system. A team that is responsible for multiple products is asking for all their products to be put under a single TFS project. Their reason is because the products are all in a similar domain.

Here are my reasons against:

• The workspace mappings will get weird, since projects will be mapped to subfolders
• Continuous Integration may be a problem, since a single project can't be referenced
• Tracking history of source control activity could be problematic

This just feels like an overall bad idea, but I would like some concrete reasons against it. If I'm completely off-base and this is a good approach to take, I'd like to hear that as well.

What are the pros/开发者_JAVA百科cons?

---

I have experience storing multiple Visual Studio Solutions (seperate products) under one TFS Team Project in both TFS2008 and TFS2010. Here is my take.

In both versions we create a folder for the Product, then a folder for the branches (Main, etc.) This makes it easy to see what product we are working on, and we can see the history of the product seperate from other products. Continuous integration works just fine with multiple build definitions, one for each product. We only create one workspace mapping for the entire TFS Team Project.

The shortfall in TFS2008 is that it can be difficult to manage work items for each Product. In TFS2008 the work items apply to the entire Team Project and it is not as easy as it should be to figure out which work item belongs to which product.

In TFS2010 the work items have an Areas and Iterations section. We use the Area to define the Product. So each Work Item gets an Area that matches the Product name. This has worked very well for us.

If you are not using work items heavily in TFS2008 than I don't think you should avoid putting multiple Products in one TFS Team Project, certinally not for the reasons you listed above.

Using one Team Project does haves some advantages: 1. There is ony one Team Project to manage and there is only one Share Point site. 2. You can see history across the entire Team Project easily.

---

My thoughts:

If there are assemblies shared amongst the projects, it makes sense to lump them together, otherwise you will run into the same problems that many people have discussed here, on how to handle shared assemblies.

You shouldn't encounter any problems with workspace mappings. Within our organization, we simply map $/ to a folder and go from there. Otherwise you could very easily map individual source control folders to different areas on disk. The only recommendation I would have is to put that mapping in a batch file, so that new members can run the batch and be consistent.

The only thing that you might lose out on a bit by lumping these all together is quick and easy reporting. If everything is in its own Team Project, the built-in reporting works "out of the box." If you put things together, you'll need to set up additional areas and iterations in order to do the reporting and tracking.

In our organization we have upward of 15 separate team projects, but every single one of them has more than one "product" underneath. We've been running this way for two years and really haven't had any problem with it, with the exception of the reporting.

---

Using a single Team Project for more than one software is a perfectly acceptable solution if you don't use separate templates for them. Martin Hinshelwood has a detailed blog post on the subject.

http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/