1

Is it possible to do a "pre check-in" in TFS?

My scenario is I want code auditors do the code audit before it is committed to source control. This ensures code quality and architecture check compliance within my company's internal practices.

Like when a programmer checks-in his/her codes, a notification automatically sends to the code auditor and that auditor checks for compliance and commits it to source control.

Thanks!

Floyd Que
  • 119
  • 1
  • 1
  • 5

1 Answers1

2

In TFS there is a concept of a Shelveset. This is a checkin that is not committed to source control yet (kinda a soft-checkin). Other members of your team can access your Shelveset too.

In TFS 2012, they introduced a code review system which is built on this Shelveset system.

More info here: http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-Using-Code-Review-to-Improve-Quality

Shelves have many uses (taken from here @TJB)

  1. Context Switching: saving your work on your current task so you can switch to another high priority task. Say you're working on a new feature, minding your own business, when your boss runs in and says "Ahhh! Bug Bug Bug!" and you have to drop your current changes on the feature, and go fix the bug. You can shelve your work on the feature, fix the bug, then come back and unshelve to work on your changes later.
  2. Sharing Changesets: if you want to share a changeset of code w/o checking it in, you can make it easy for others to access by shelving it. This could be used when you are passing an incomplete task to someone else (poor soul) or if you have some sort of testing code you would never EVER check in that someone else needed to run. h/t to the other responses about using this for reviews, it is a very good idea.
  3. Saving your progress: while you're working on a complex feature, you may find yourself at a 'good point' where you would like to save your progress, this is an ideal time to shelve your code. Say you are hacking up some CSS / HTML to fix rendering bugs, usually you bang on it iterating every possible kludge you can think up until it looks right. However, once it looks right you may want to try and go back in to cleanup your markup so that someone else may be able to understand what you did before you check it in. In this case, you can shelve the code when everything renders right, then you are free to go and refactor your markup knowing that if you accidentally break it again, you can always go back and get your changeset.
Community
  • 1
  • 1
gregpakes
  • 4,465
  • 29
  • 43
  • Well code review pretty well sums up majority of my issues here but what if code reviews happens maybe 24 to 48 hours after the request. What's the "best practice" to do with the Work Item when its for code review? "In TFS 2012, they introduced a code review system which is built on this Shelveset system." On your quote above, does this mean that the Work Item is being shelved while its pending review? Thanks – Floyd Que Apr 08 '13 at 14:42