Check-In Policies Pack Feedback Request

Published 13 September 06 04:05 PM

I have decided to skip the post about merge and deleted items for today in order to get some feedback from you on Check-in Policies. Currently, we are thinking of releasing a check-in policy pack out of band that includes some very commonly used policies, an example being "Check-in comment field cannot be empty".

 

The reason why I say thinking is that we need enough customer evidence to really justify the investment (we have some but not a lot), if we don’t invest time in this we can divert the effort to other highly requested items, hence the dilemma and trade-offs. So, this is where your feedback comes in: "Would you like us to release a check-in policy pack together with some best practices and ship that out of band?" (Feedback 1)

 

If we decide to do this then the next question becomes which policies are customers writing themselves that we can standardize and put in the pack? (Feedback 2) The empty comment field is a great example of one that a lot of our customers write and is standard.

 

And finally the next logical progression from here is which policies would customers like to see as examples? (Feedback 3) Maybe you want to write a policy but you think is very complicated and are wandering if there is an easier way to perform that task, etc.

 

Summarizing we need your votes for the first one, the more votes we get the better our decision will be. Then if you have thoughts and ideas on #2, and #3 let us know in the comments.

 

Thanks,

mario

by mrod

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# bharry's WebLog said on September 13, 2006 12:34 PM:
We are in the (very early) planning process for the next TFS Power Toy release.  You can read my...
# Rob Caron said on September 13, 2006 2:30 PM:
Microsoft bloggers frequently blog their interest for receiving your feedback on ideas to improve our...
# KeithH said on September 13, 2006 2:45 PM:
I think a policy to warns folks that a partial checkin (not all pending changes are checked in as part of the changeset) could potentially break the build.  It could suggest shelving the files that won't be checked in, reverting back to the workspace baseline versions for those files and requalifying (compile & test) before continuing with the partial checkin.  Yeah we're seeing a number of broken builds occurringd due to partial checkins.  Of course perhaps CI is a more appropriate response to this problem?
# mvarblow said on September 13, 2006 4:00 PM:
Would you like us to release a check-in policy pack together with some best practices and ship that out of band?  

Yes, please!
# FreeToDev said on September 13, 2006 5:26 PM:
This 'pack' is not something I really need at the moment. I'm able to enforce the comments policy with the checkforcomments policy that's on the web (google it). I use this policy, the ForbiddenPatterns policy and the CustomPath policy.
If I need anything else, I'll hopefully find it out there or write it myself.
What I'd really like to see is SP1 for the product and more so Visual Studio 2005 which is appallingly buggy.
# JoeZ said on September 13, 2006 5:54 PM:
Feedback 1: I think the pack would be a great idea.

Feeback 2: I'm not sure on this. I'm looking to enforce standard C# style rules, but it looks like many of those policies already exist. Maybe a single toggle specifically for naming conventions? Search and destroy on hungarian notation, missing { brace going into for loops, etc.

Feedback 3: Personally I'd like to see example policies that check the case on identifiers (although it looks like many of these policies already exist).

# jsamuel said on September 13, 2006 6:31 PM:
Feedback 1:  Yes please.

Feedback 2:  Enforce Comment, Enforce a successful compile since last edit (no errors, optionally no warnings)
# Buck Hodges said on September 13, 2006 11:30 PM:
Mario Rodriguez, a program manager on TFS version control, is seeking your input on what you need...
# Buck Hodges said on September 14, 2006 12:02 AM:
Mario Rodriguez, a program manager on TFS version control, is seeking your input on what you need...
# noocyte said on September 14, 2006 4:00 AM:
Would you like us to release a check-in policy pack together with some best practices and ship that out of band?  

Yes, please! :)
# huckes said on September 14, 2006 4:59 AM:
Mario - I feel obliged to reply to you as you were obviously reading a comment on the forums I made.

Feedback 1: I think a pack would be a good idea or at least a reference of "good" policies that have been created. I think it would be helpful though if the pack offered an easy installation route for the policies or showed how this could be done simply.

Feedback 2: Apart from those already mentioned, I think the Time that Task policy that allows developers to enter time worked to date on a task at code check-in time would be useful to include.

Feedback 3: I think a pack should also describe how to do certain things by way of example; e.g. how to prevent check-in of code if a certain field in an associated work item has a certain value. This is useful for forcing something like a peer review to take place if a field of Review Required is set.

Extending this further to be able to check if a field in the work item is inappropriately set would be another example; i.e. If a peer review is required then make sure the peer reviewer field has a valid user entered, but NOT the user who is doing the check-in.

Ultimately a set of examples that show how to manipulate work items and also how to reference the user would be very useful.

Regards

Steve
# Mike Attili said on September 14, 2006 8:24 AM:
1: A policy pack out-of-band would be useful
2: Currently using 'Work Items', 'Code Analysis', and 'Check for Comments'. Additionally, I'd like to see a policy enforce that project references are either references to another project in the solution, to a permitted set of assemblies (System, System.XML, ... [customizable]), or within a certain relative path. I frequently see problems with developers referencing assemblies that are only installed locally but not in source control.
3: The "Project Reference" policy could make a good example.

Before I vent, let me say that I'm very happy with the pending changes and check-in policy functions in VS; but...
Two additional comments:
First: The 'Check for Comments' policy is quite buggy and should be fixed. It fails when files are linked into multiple projects; with some VS add-ins that play fast&loose with the VS object model (The latest InstallShield is a prime example); and when the cached project files get out of sync. I've often seen bugs in this policy take down my VS session and it's reproducable.
Second: When a policy throws an exception, the message displayed in the Pending Changes-Policy Warnings list is misleading. I frequently see the following: "Error in Ensure that code analysis is run with a defined set of rules." when the 'Code Analysis' policy throws an exception. The message should probably indicate that an exception was thrown and use the policy type set off in quotes rather than the polcy description just run in with the rest of the message. If you then double click on the message, a dialog box is displayed with only the message text of the exception. This has also been misleading since in the first instance, this happened to be a NotImplementedException and the dialog implied that double clicking on the policy warning wasn't implemented rather than that this exception was thrown by the policy itself. Lastly, when debugging check-in policy exceptions, it would be very helpful if double clicking produced a stack trace in addition to the exception text.

Thanks,
  Mike
# Team System News said on September 14, 2006 10:24 AM:
Aaron Hallberg on Team Build API: GetBuildURI and GetBuildDetails.

Brian Harry on The Next TFS Power...
# ashankz said on September 15, 2006 7:36 AM:
Hi, I have a suggestion on Code Analysis check-in policies.
We have customized some naming rules. Hence some default naming rules don't apply and we disble them.
Currently in TFS we have to configure which all rules to run for each project.

It would be good if we can have a central way of configuring the set of rules for all the projects, rather than setting them at each project.

Individual project admin should have the ability to override the configured set of rules.
# sergio said on September 22, 2006 8:03 AM:
Feedback 1: Yes, please

Feedback 2: I agree with JoeZ, and will be great to have some kind of coding conventions policy. This policy can be as complete/complex as desired (some examples could be the following):
 - Curly Brackets style
 - Hungarian notation
 - Comments present and with the correct format (on files, functions, etc...) based on development team conventions
 - Size limits (number of line of files or functions, long lines, long variables, methods, etc...)
 - Keywords/funcions not allowed (i.e. deprecated ones)
 - Conventions on how to declare structs, enums, class, etc...
 - Comments Spell check
 - Duplicate code checks
 - External Program execution. I.E. To integrate VSTS with bigger policy checking systems like SourceForge Checkstyle or Parasoft C++test.

Feedback 3: Would be great to have samples covering completely different situations.

Regards,

Sergio
# kevik said on September 28, 2006 5:48 AM:
1. Yes please to the pack.

2. I've downloaded and extended TimeThatTask so that the update takes place after the checkin event.
  I've created an EnsureReviewerValidity policy that checks a name in a 'Reviewer' Checkin note, that in turn generates a Review work item after the checkin event.
  I've downloaded EnsureCommentIsPopulated and CustomPath.

3. I'd like to see a policy that checks your workspace is up to date before allowing you to checkin.

Thanks.
# kcastle said on October 8, 2006 12:48 PM:

1. Please, Please add a checkin policies pack

2.

- Coding convention policies would be a huge plus.

- Required comments is a must.

3. I noticed that someone had mentioned that entering the time required for checked in items, would it be possible for that data to be added to the TFS Warehouse along with any other info which could be calculated during checkin. An example that I am thinking of would be the LOC associated with the Check-In.

# Mike's Blog said on November 20, 2006 3:16 PM:

There was a recent TFS Version Control Blog post which asked the community for feedback regarding TFS

# TFS Version Control and more Check In Policies Pack Feedback Request | storage bench said on June 19, 2009 4:17 AM:

PingBack from http://thestoragebench.info/story.php?id=8512

Leave a Comment

(required) 
(optional)
(required) 
Page view tracker