This has created a workItem outbreak

Aug 22, 2014 at 6:27 PM
This trigger was in place for quite a while before I got involved, and it seems that it has created a massive problem while nobody was looking.

Here's the scenario:

Let's developers work on various work items in various branches. Let's call them DevA, DevB, DevC. That work gets downmerged into a parent branch, Dev. Then everybody does an upmerge from Dev into their branches, DevA, DevB, DevC.

Now All of the work items associated with each of the downmerges is now associated with the upmerge changesets. In other words now every file involved in all of the work downmerged from DevB and DevC is now associated with a changeset in DevA that includes changes from Feature A, B, and C.

Now say someone in DevA edits one file from Feature A, and then merges down to Dev. Now all of the work items related to everything described above are now associated with that single file downmerge.

Skip to two years later, and now we have two years worth of work items getting associated with every merge. Queries run like molasses. It takes 5 minutes to view the work items associated with a single changeset, and I can't get reliable information about what I'm releasing, because totally unrelated work items have infected all of the changesets.

I'm now working on a script to disassociate previously-released work items from all downmerge candidates, but this is going to be a very slow script given the heuristics that I need to implement to make this work.

I'm surprised that this doesn't happen to everyone who uses this trigger. Is there something that i'm missing here? Does something in our process violate the intended use?