TF201001 is an error you can get when working with custom link types, and is time-consuming and disruptive to resolve, so merits discussion.
First, some background… before TFS 2010 you could link work items together, but couldn’t specify what their relationship was. In TFS 2010 you can do that, because there are different link types to choose from including parent/child, successor/predecessor and related. As you may guess from the names, each of these link types has rules that define how they can be used, called a topology. For example:
- Parent/child uses a tree topology – meaning that relationships must be one-to-many and cannot be circular. So a child can only have one parent (only in the field of computing could that statement pass without bemusement).
- Successor/predecessor uses a dependency topology – meaning that relationships are many-to-many but cannot be circular, and the direction determines what name is given to the link.
- Related uses a network topology – meaning that anything goes, including circular relationships, and the link has the same name regardless of direction. It indicates that work items have something in common without saying exactly what that is.
You can use the link types that come with TFS 2010 to define richer relationships between work items, but you can also create new custom link types.
You define a custom link type in an XML file like so:
<?xml version="1.0" encoding="utf-8"?> <LinkTypes> <LinkType ReferenceName="MyCo.LinkTypes.Releases" ForwardName="Releases" ReverseName="Released By" Topology="Tree" /> </LinkTypes>
And upload it into TFS using witadmin:
witadmin importlinktype /collection:http://myserver:8080/tfs/DefaultCollection /f:"LinkType_Releases.xml"
This particular link type was created so TFS could be used to track complex configuration changes, linked together under a new Release work item type. The thinking at its creation was that one work item could only be linked to one Release, so the Tree topology was the right choice. It later turned out that under some circumstances one work item could be included in multiple Releases – which is prohibited by the one-to-many rule of the Tree topology.
So the logical decision is to modify the custom link type to the Dependency topology, which (sadly) results in:
TF212018: Work item tracking schema validation error: TF201001: Cannot change topology for a link type MyCo.LinkTypes.Releases, it has already been defined.
Ouch! Even though I want a less restrictive topology, TFS prohibits the change. There is no simple way to get around this – getting the change in place requires a tedious workaround such as:
- Rename the existing link type
- Create a new corrected link type
- Change all of the work items using the old link type to the new link type
- Delete the old link type
I can understand that changing a link type to a more restrictive topology could invalidate existing links, so it makes sense to prohibit that change, but why not allow a change to a less restrictive topology – which cannot possibly cause that problem?
I’m guessing that Microsoft either didn’t think of this scenario, or thought it too rare to accommodate. Either way, the lesson is that custom link type topologies should be chosen with great care and, if in doubt, choose the one that is less restrictive!