A few words about the integration into TFS of a defect management system with a version control system

Introduction

I continue to be surprised to share the experience of switching from SVN to TFS (or as Team Foundation Version Control (TFVC) was correctly noted).
In a previous post , the experience of a pure version control system was described.
In this post, I would like to share a small (but important) scenario for using the integration of the "version control" system with the "defect management" system (or as it is called Work Item Tracking).



One of the most frequent (for me, and it seems to me for others) scenarios of integration of systems of “version control” and “defect management” is the linking to the “defect” of relevant changes in “version control”. It often happens that one “defect” (or task) is solved with the help of several changes (revisions).
This scenario seems to be completely unsupported by SVN and out of the box it supports TFS perfectly, at least that's what Microsoft sellers do.

In reality, we use a simple trick in SVN that allows several things:
- First of all, you can associate each revision of SVN with a certain number of TFS “defects”;
- and vice versa, each defect can be associated with a certain number of revisions;
- Further in the history window you can see the column with the numbers of TFS defects for each revision ;
- it is clear that a click opens the web interface of the defect;
- Naturally the story is edited (i.e. defects can be changed).

When a programmer commits, he can indicate the defect number:


The history shows a column with defect numbers:


The story implemented by TortoiseSVN provides a very easy way to find all revisions related to a particular “defect”: you simply write the number of the “defect” in the history filter and you will immediately receive all changes to this defect. By marking filtered revisions, you can see all revision data files at once .

Not out of the box? Well yes. Maybe it looks artisanal? May be.

Now let's see what level of integration I got on TFS (version control and defect management). I know 3 ways to work with TFS (excluding the command line): from Windows explorer, from Visual Studio and through the web interface.

Making “Check in” from Windows Explorer (Power Tools 2013): Tab “Work Items” allows you to search for a “defect” by number only in the current request. If for some reason there is no request, there is no commit. So, before checking in, make sure there is a request ladder by which you can find a "defect".

We do "Check in" from Visual Studio : Studio allows you to add a number of "defect" on request and the actual number.

The web interface for this scenario is not relevant.

Now how to search for revisions by the number of “defect”:
Windows Explorer (Power Tools 2013) does not have a search, in order to find out which “defect” is associated with a revision, you need to select the revision and switch the tab. Thus, it is not possible to find all revisions of this “defect”.

Studioalso does not have a search (revisions for a “defect”), but it allows you to find out its revisions by a “defect” (tab Links). Now you can click on these links to see which files have been changed. I did not find a way to see all the changed files (and in the Studio it is just not convenient).

The web interface is certainly more colorful and not bad for visualizing changes in one revision, but it still is not suitable for several revisions.

Conclusion :
Power Tools looks wretched for this scenario. The studio wins against TortioseSVN due to requests for checkin.
Finding and visualizing changes (especially when there are several revisions) is significantly better supported in TortioseSVN.
A little (or a lot) is the annoying change of tools (Power Tools, Studio and web), so there is no one that works better than others.

Notes:
- Sorry for the terminology: sometimes I get confused.
- I agree that I "did not understand TFS before using it." Help me to understand.