How do I find dependencies between sourcecode/changeset/workitems

My company are trying to use CMMI in TFS for our development.

In CMMI is used a Change Control Board, a board of people deciding which changes that can be included in the next release.

The way I am planning to work is to make a developer branch where all developers deliver there work.

My job as a configuration manager is to make a list of all changes (as workitems) to the configuration board, so they can decide which workitems they want to include in the next build. Then I cherry-picking the workitems and merge them into the last release in another branch.

My question is, how do I find dependencies between the changesets (Seen from a workitem point of view)

An example.

Developer one, creates a date converter function in a common func package and check it in with a association to workitem #1

Developer two, creates a screen using the date function created in workitem #1, he checks it in with a association to workitem #2

Developer three creates another screen using the common func package but not the date convertion func.

Now I want to create a report to the change control board stating which workitems there are ready to include in the next build.

The report I need is one saying that if I want workitem 2 to be included I have to pick workitem #1 as well due to dependencies.

I don’t need to include workitem #1 if I only will include workitem #3 because it can use an old version of the common package.

Is there a way to do this in TFS

Is there any form of warning if I try to merge a workitem that have a dependency that are not included

Visual Studio Team System21

There's no built-in way to do it. The reason has to do with determining that the code in changeset associated with workitem #2 depends on code in the earlier changeset. Determining that would require that TFS understand the programming language being used.

One way to deal with this would be to use shelvesets instead. When a change is made, the changes are shelved. If the board approves it, the shelveset is unshelved and checked in. With that approach, the date conversion function would either need to be approved and checked in before code could use it, or it could be combined with the work item that needs the code, which means that both changes would be in the shelveset and taken together or not taken at all.

Buck