Geek asks and answers

Is storing multiple products in a single TFS project a bad idea?

We have Team Foundation Server 2008 deployed as our source code management system. The team that is responsible for several products asks that all their products be delivered under the same TFS project. Their reason is that all products are in a similar domain.

Here are my reasons against:

  • Workspace mappings will become weird as projects will appear in subfolders
  • Continuous integration can be a problem because one project cannot be referenced
  • A history of tracking version control activity can be problematic.

It just seems like a general bad idea, but I would like to find some specific reasons. If I'm completely out of the base and this is a good approach, I would also like to hear that.

What are the pros / cons?

+3
source share
3 answers

I have experience storing several Visual Studio solutions (individual products) within the same Team TFS project in both TFS2008 and TFS2010. Here is my trick.

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

TFS2008 , . TFS2008 Team Project, , , .

TFS2010 " ". Area . , , . .

TFS2008, , Team TFS, , .

Team Project : 1. Team Project , Share Point. 2. Team Project.

+4

:

, , , , , , .

. $/ . . , , , .

, , , - . Team Project, " ". , , .

15 , "" . , .

+2

Using one Team Project for several programs is ideal if you are not using separate templates for them. Martin Hinshelwood has a detailed blog post on this subject.

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

0
source

More articles:


All Articles