Disposing of checkin policy

Recently while I was fixing up StyleCop checkin policy, I came across one small not-so-obvious snippet of knowledge worthwhile to share.

Any custom checkin policy inherits from PolicyBase, which in turn implements IDisposable. Meaning – if you need to clean up after yourself in your custom policy, Dispose method is the place for that.

So in StyleCop policy, I do a lot of Visual Studio related stuff and thus I thought I’d dispose of VS extensibility objects in Dispose method.

And here where non-obvious stuff starts. The policy is loaded in either of those cases:

• Project Source Control configuration (through menu Team->Team Project Settings->Source Control)
• Right-clicking in Solution Explorer and invoking “Check In…” menu
• Invoking “View Pending Changes” toolwindow

While the first case is not very interesting (no pending changes will be evaluated in configuration), two other cases are important.

In case of “Check In …”, “Check In” modal window is displayed (the policy is loaded), and when window is closed, custom policy class is unloaded and Dispose called. However, in case of “View Pending Changes” toolwindow the policy is loaded once when window is first created, and Dispose will be called only when Visual Studio is closed or TFS server connection is closed. That means you probably should not hold on any expensive resources until Dispose.

New check-in policy for VSS fans: keywords expanded

One of the much-talked-about missing features of TFS is the keyword expansion feature. You know, the ability to place the template in the beginning of every single file and then have every revision tracked in the body of the file (in addition to tracking in source control history, that is).

Personally, I am not a huge fan of the feature – mostly because the usefulness of the feature limited by the following factors

1. The comments to check in still have to be detailed (if the comments are crappy, you get a lot of garbage in the file that adds nothing)
2. If the file gets branched a lot, the revision history tend to get muddy and not to reflect the branching history very adequately
3. If the code churn is great, you might get 100 lines of code adorned with 400 lines of revisions history (yes, I actually seen this)

So I am of the opinion that all of the above is the function of source control and if your source control is not good enough for tracking history of changes – that ain’t good source control :) However, for some folks ability to have history of changes contained in the same file outweighs the disadvantages. And these folks were pretty vocal, so vocal that Buck Hodges stopped one stop short of writing actual solution and provided the verbal recipe for writing one, using check-in policy as a workaround (since keywords expansion is not making it into official product).

And voila! Two years after this post was published, there appears TFS keyword expansion checkin policy, written by Jochen Kalmbach. Jochen also published the policy on CodePlex site, under the name of LogSubstPol.

I did a short test drive of the policy, and it does work as advertised, in three simple steps:

1. Install the policy (currently using batch script)
2. Add the policy to your Team project and configure the format of the keywords string
3. Add  keyword ($log$ etc.) monikers to the file modified prior to check in

Once all of that done (and steps 1 & 2 are once per project, step 3 once per file step), as you check in you will see the revision history being updated and checked in as part of the file.

While the policy is awesome, there are few things to be aware of.

• As the policy requires you to supply the comment, it effectively replaces “Changeset Comments Policy”, so if you have it defined for Team project you might want to remove it
• Configuration dialog for the policy is somewhat complex, so read the documentation first (supplied PDF is real good)
• If you evaluate the policy but decide not to check in, due to limitations of the checkin policy mechanism the keywords in the file will get expanded anyway
• As the files are updated by the policy, VS will display the message “The file has been modified outside of the source editor” (as policy touches it right before check in). That again may be limitation of the checkin policy mechanism for keyword expansion (but perhaps can be mitigated with some creative VSX tweaking)

But regardless of these small thingies, the policy is mighty useful and it fills the big gap for those accustomed to keyword expansion. Big kudos to Jochen for creating the policy!

Mirror from MSDN blog