You can limit "Check-In Policy" rules via the "Custom Paths" policy. But the "Check-in Notes" tab doesn't seem to fit in to the same system. Why isn't "Check-In notes" just another "Check-In policy"??
I'm using Team Foundation Server 2008 SP1
You can limit "Check-In Policy" rules via the "Custom Paths" policy. But the "Check-in Notes" tab doesn't seem to fit in to the same system. Why isn't "Check-In notes" just another "Check-In policy"??
I'm using Team Foundation Server 2008 SP1
That's an interesting question - the short answer is you cannot.
I have ran into the issue myself a lot where people get check-in notes and check-in policies confused because, while very different in implementation on the server, they often serve similar purposes.
Check-in notes are bits of structured meta-data that you want to collect on every check-in to a Team Project. They can be thinks like who was the code reviewer or a reference to a ticket in an external CRM system or something. You can make them required, or just have them defined for people to optionally fill out.
Check-in policies are bits of code that run on the client at the point of check-in that get a say if the check-in should be allowed or not. These are useful for checking things like you have associated a check-in with a work item, given it a comment or the code you are check-in in passes certain key static code analysis rules (such as basic checking for SQL injection attacks etc). If a check-in policy fails in the evaluation of the check-in then the user gets alerted and they get the ability to fix the problem or check-in anyway with a check-in policy override than can easily be reported on or alerted for by the TFS administrator.
Both check-in notes and check-in policies are defined and scoped at the Team Project level. However, Microsoft got feedback that some people would like check-in policies would like to be applied to specific paths in version control rather than just the Team Project and so the Custom Path Policy was invented.
The Custom Path Policy is a bit of a hack that allows you to wrap check-in policies inside the custom path policy. The custom path gets evaluated on every check-in and if it contains files inside the defined path then the wrapped check-in policies are evaluated for those files. The Custom Path Policy ships in the TFS Power Tools and is not part of the "Out The Box" TFS experience.
So, to answer your question a different way - I suspect the answer is "because that's the way it was designed and not enough people have asked for it to be changed".
If you wanted to leave feedback at http://connect.microsoft.com/VisualStudio I know they take customer feedback very seriously.
We had a similar problem some time ago. For some sub tree we wanted to require entering a code reviewer. I ended up implementing a custom policy and used the Custom Path Policy to restrict it to certain folders. That works well, except that you have to deploy your policy assembly and TFS has no built-in mechanism for that, yet.