134
votes

We are beginning to use the code review functionality built-in to VS 2012 and VS 2013 preview. Requesting the review and adding comments seem pretty straightforward. If someone adds comments requesting the code to be changed, then how does the requester make these changes and show them?

So the process would flow like this:

  1. Person 1 requests a code review.
  2. Person 2 adds comments and selects "Needs Work."
  3. Person 1 makes the necessary changes.

How does Person 1 now show these changes to Person 2? You can add comments and send them, but the files don't change. I'm assuming the files are from the changeset created when the original review was requested. Should Person 1 close this review, and request a second review?

Creating a second review doesn't seem optimal, because you lose the history of your conversation of why you were making the changes.

There are ton of websites showing how to use the basic functionality of the code reviews, but are there any sites that show the best practices? For instance, who should be clicking the check boxes next to files?

4
+1 for "are there any sites that show the best practices". The ALM Rangers are usually my "goto guys" for in-depth usage, but the only information I can find, doesn't answer your question. I would love to see some walkthoughs and scenarios for using Code Review.DaveShaw

4 Answers

174
votes

So the process would flow like this:

  1. Person 1 requests a code review.
  2. Person 2 adds comments and selects "Needs Work."
  3. Person 1 makes the necessary changes.
  4. Person 1 Updates the shelveset associated with the code review
  5. Person 1 adds comments to continue the discussion
  6. Repeat steps 2 - 5 until accepted

Here are the steps necessary to update the shelveset associated with the review.

  1. From the "Code Review" pane select the "view shelveset" link
  2. From the "Shelveset Details" pane highlight and copy the shelveset name
  3. Navigate to the "Pending Changes" pane, click on "Shelve" and paste the shelveset name
  4. Press the Yes button on the shelveset replace verification dialog
  5. Now the reviewer can see the updated files and the review discussion can continue

I've included some screen shots as I find it helps to clarify things.


1) From the "Code Review" pane select the "view shelveset" link as shown here:

enter image description here


2) From the "Shelveset Details" pane highlight and copy the shelveset name as shown here:

enter image description here


3) Navigate to the "Pending Changes" pane, click on "Shelve" and paste the shelveset name for example:

enter image description here


4) Press the Yes button on the shelveset replace verification dialog:

enter image description here

6
votes

I believe the correct procedure is fore Person 1 to make the changes and request another review. When your code needs work that means you will be changing it so you will want to have the old version to look back to for comparison. You still have the old review in the history after it is closed if you wish to look over the comments. We are currently in the process of optimizing our code review process in my workplace.

3
votes

I know this question is old, but it's still not supported as pointed out by other posters. The solution proposed by chad will work for some things but will have odd behavior for others.

Recently, the TFS team began the planning stages for a solution to a very old uservoice request to enable updating of a Code Review now migrated to developercommunity.visualstudio which should elegantly solve this problem by making Code Reviews have iterations.

0
votes

You have to do this with two different reviews. But there is also a way to keep the history with the second review. All you need are tasks.

This workflow is described for changeset based reviews, but it works also for shelve based reviews.

  1. Create task1
  2. Before checking in changeset1 add task1 as a related work item
  3. Check in changes with one work item related and request review to this changeset
  4. Create task2
  5. Before checking in changeset2 add both tasks as a related work item.
  6. Check in changes with two work items related and request review to this changeset

Now in the second review request the reviewer is able to look for related tasks and if the reviewer takes a look for task1 he/she sees the changeset1 and the review request with its comments. So you wont be losing the conversation history.