Require Story/Issue Reference with TFS Commit Comment?

I recently joined a project team that is using TFS (I have happily avoided TFS until now). I am trying to determine if there is a way to require a story/defect reference to be associated with every commit comment?

With Tortoise/SVN it was easy to add a requirement for a reference number to be required with each commit. Personally, I like to track every commit back to a user story or defect, so I am hoping there is a way make this mandatory in TFS as well? I searched SO and Google, and haven't found the magic "key words", so if someone can point me in the right direction, it would be greatly appreciated.

Not开发者_JAVA技巧e: Stories and Issues are stored in other tools and not tied to TFS in any way.

Can it be done? Yes. Is it easy? Fairly easy. However, two caveats. Caveat number one: you're going to have to write code. Codeplex has some good examples here. Additional searches on codeplex and on the almighty Google will locate you more examples.

The big caveat here is that check-in policies are client-side. Once you develop the policy, it will need to be deployed to all developer workstations. If the policy isn't installed? It is ignored. While I'm a big fanboy of TFS, this is one oversight that I can't believe is still in place after three major version releases.

You could create a server-side check-in monitor that examines the check-in and determines if the story has been associated. However, it will not prevent the check-in, but you can use it to alert someone to resolve it after the fact.

Switch to a DVCS system like Git (see this article on pre-commit hooks) or Mercurial (see this other article on pre-commit hooks) which DO have server-side hooks that can be overridden to do validation checks. :-)

Yeah, I know, not really the answer you were looking for but it is an alternative solution to the problem that some other SO users might find useful.

With the DVCS type of system, you can have a separation between hooks that run on the local computer and hooks that run on the server when your commit is pushed back to the shared repository. That kind of concept does not have a corollary in TFS. It can make some things easier for your developers. For example, every changeset that was committed to our shared repository had to have a ticket number attached in the commit message. Local pre-commit hooks guarded against changesets getting created (in Mercurial) that did not have proper commit messages.

With TFS's support for GIT in an upcoming release maybe things will be easier in this regard.