Normálně píšu na svém blogu česky, ale tentokrát to může být zajímavé i pro ostatní, proto přepínám do angličtiny... switching to English...
Recently, I have prepared three TFS checkin policies for a customer. They hope they will find them useful so I hope you might find them useful as well. Source code is included as an attachment at the end, there are no licensing or copyright restrictions – use at your will. Enjoy!
Same Branch Policy
Same Branch Policy prevents users from accidentally checking in into more than one branch with a single changeset. This is usually an unintentional mistake – vast majority of changesets should contain files that all belong to the same branch. This mistake creates confusion and costs extra work to rollback and correct when it happens. Originally, I thought about automatic evaluation from the tree of branch relations but customer was afraid that this won’t work correctly for all variations of branching schemes, so branch definitions are created manually:
When this policy is not satisfied, user is defined in a standard and understandable way:
Path Validation Policy
This policy is an expanded version of Forbidden Patterns Policy from TFS Power Tools. It checks for patterns in file paths and offers an extra level of comfort and flexibility such as:
- More comfortable rule definition – for many cases, StartsWith and EndsWith are more handy than regular expressions.
- Customizable error message for each rule
- Ability to prompt the user without actually violating the policy
- More readable policy violation messages
See screenshots below:
Import Project Policy
Customer wants all the projects in a solution to import some standard settings, such as Code Signing, via <Import Project=”…”/> in MSBuild files. This policy checks whether projects in a solution import required settings and if this <Import> is the last subelement in a file (and thus cannot be easily overridden):