Using separate TFS projects for source control and work item tracking, is this a good thing?

Question

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.

thx

Answer 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.

Answer 2

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.

Answer 3

Mr. Krause,

I'm curious, how well did this work out for your organization? Our group is considering doing this as well. We have two projects that need to have separate source code check-in policies, and yet we would like to have all work items in one cental TFS project.

Any insight on how this worked for you would be much appreciated.

Thanks, John