Creating TFS Custom Check-in Policy – Part 2

April 23rd, 2014

This is the second article of the two-part series that explains implementation of the TFS custom check-in policy for pre-commit code review. We developed this policy for Review Assistant – our code review tool.

In the first article we explained what is a check-in policy and what is the implementation procedure. This article shows nuts and bolts behind our implementation of a check-in policy.

In this article, we shall discuss:

  • The algorithm of our Pre-Commit Code Review policy;
  • Main problems of implementing the algorithm;
  • Restrictions of the policy implementation.

How Does the Pre-Commit Code Review Policy Work?

Here is the policy algorithm description in a nutshell:

  1. Once a user invokes the Check In Pending Changes command or just opens the Pending Changes view in Team Explorer, the policy is evaluated.
  2. The policy loads the Review Assistant package and attempts to connect to a review server using previously stored credentials.
  3. Policy searches for the open reviews for the pending changes. There are three possible outcomes:
    1. No review is found – the policy is not satisfied.CheckinPolicyWarning
    2. An open review  is found –  the policy is still not satisfied.CheckinPolicyWarning2
    3. A closed review is found – the policy is satisfied (no warning).
  4. A user activates the policy (when it’s not satisfied). Here we have two scenarios:
    1. There are files that require the code review.
      1. A shelveset with pending changes is created
      2. Code Review Board is opened and the new review for the above shelveset is created.
      3. The user specifies a reviewer and publishes the review.
    2. Files in the pending check-in are under review.
      1. Code Review Board is opened and the review, which causes the policy to fail, is displayed.
      2. The user can check the status of  the review and push the things forward, if necessary.

Note: When the policy fails to evaluate correctly it returns no failure. In other words, if it fails to connect to a review server the policy is still satisfied.

Tough Point of the Implementation

The main problem of the pre-commit code review process lies in creeping changes. Developers are constantly changing the code, even while the review is in process.

Thus, we faced the dilemma: how to identify what code was reviewed and what wasn’t. It’s not enough to identify the files that were changed. We want to make sure that the file content remains stable throughout the review.

The solution we chose was to calculate MD5 hash of each changed file during the policy evaluation. Fortunately, the policy evaluation runs in a background thread and doesn’t block the Visual Studio UI.

These hash-values are stored locally on user’s computer. We maintain a sort of cache for the reviews created by the user. This saves time on searching the reviews for the pending changes.

Policy Restrictions

Finally, we’ll cover the restrictions of our Pre-Commit Code Review policy.

  • Policy does not filter the files during the evaluation. It will fail even if you change supplementary files that don’t need a review. In this case you should override the policy warning.
  • If you add files to your check-in after the review is created the policy will fail. In this case you should remove additional files from the check-in to satisfy the policy.
  • Reviews created by the policy are cached for a limited time. But it won’t be an issue unless you delay the check-in for a month.


We’ve covered some detail of the implementation of Pre-Commit Code Review policy in Review Assistant. We hope it helps you in using our product. Download Review Assistant and start reviewing code today.


3 Responses to “Creating TFS Custom Check-in Policy – Part 2”

  1. Creating TFS Custom Check-in Policy – Part 1 Says:

    […] […]

  2. Beez Says:

    You might want to fix the typo above…

    “Download Review Assitant”

  3. Alex Serdyuk Says:

    Thanks, it’s fixed.

Leave a Comment