1

I have a client who is using one TFS project just for source control only and now wants to manage work items in a totally different TFS project, using a different process template, and intends to link changesets to work items across TFS projects.

I know that this is possible in TFS, but don't know what the limitations or issues that come with this configuration. e.g Build Summaries, Reporting, etc.

I would prefer branching the code into a new TFS project and managing code and work items together in one project, but need to know how the above method stacks up.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Mr. Kraus
  • 7,885
  • 5
  • 28
  • 33

3 Answers3

1

It'll work - I've occasionally had to associate checkins with work items from other projects. I haven't noticed any issues with reports or the like, that said this seems like an overly complex arrangement with little benefit.

Scott Weinstein
  • 18,890
  • 14
  • 78
  • 115
0

Seems like a strange set-up to me. While it will work, TFS is designed for the check-ins and work items to be in the same team project so you won't really get the full benefit of the TFS features. Does the client know that they can modify the process template of the existing team project or do what you say and branch or even just move the source into a new team project.

Martin Woodward
  • 11,770
  • 31
  • 45
  • Client has been advised, but likes the idea of adding other TFS projects for source control and managing all of them with work items from a centralized TFS project. – Mr. Kraus Oct 10 '08 at 04:43
0

We used this model to allow us to have separate projects but against the same source branch. It worked for a while but once we started being more adventurous with branches the model broke down. So as others have noted, there's no reason why technically you can't do this, it's not standard.

Stephen Connolly
  • 1,639
  • 10
  • 15