TFS Code Reviews - Show updated files in response to comments

Question

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?

Pursuant

+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. – Clastic

Answer 1

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:

---

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

---

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

---

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

Accompanyist

The issue with this solution is that it is destructive in that all the comments are blown away. I think a better solution would be to create a new code review and set the old one as a related item. – Zanezaneski

Replacing the shelveset does not touch the comments only the files. Our team uses this method successfully and we do not loose any review comments. – Accompanyist

This is the best answer so far. I will share this with our team. – Pursuant

This works, but if you add/remove lines when you edit a file and replace the shelveset, the comments that were on that file will point to the wrong lines. – Izanagi

This doesn't work for me. After the requester replaces the shelveset, the reviewer gets an error when trying to open the code review. It states that the shelveset can't be found or I don't have permission. – Abbott

What version of TFS and VS are you using? When you replace the shelveset do you see the final verification dialog? – Accompanyist

How did the you figure this out!! Rocket! This should be a "feature" but this work-around rocks the suburbs. – Hypozeugma

I usually don't like to repeat, but @Chin's point above makes this answer completely untenable. Yes, you can easily update your shelveset but doing so makes essentially ALL previous review comments now pointing to WRONG text. (Because apparently a review comment is attached to an absolute offset from the beginning of a file.) – Mediacy

@MichaelSorens This is a work around to provide a way for the reviewer to so see the changes made by Person 1 after the review comments. If Person 1 needs to make significant changes from the original review it might be better to close the original and open a new review. I am just trying to help work around a shortcoming of the TFS code review tool. This is not a one size fits all solution but it does work well in many cases. – Accompanyist

I appreciate your comment, Chad, and I fully understand that it is a workaround. I use TFS code review every day in my work, but this is a tremendous sore spot. (Not your suggestion, but the fact that TFS does not support revisions of a code review! :-) I am glad this workaround is useful in many cases for you but in my environment sadly it just is not useful at all. :-( – Mediacy

Too manual and not the ideal thing. TFS or Visual Studio should have something to compare the changes between consecutive reviews, so the reviewer could see exactly the changes made since the last review. Don't exist anything like this? Maybe a plugin or something... – Hellenize

@Iúri dos Anjos - I agree, this is not the ideal - it is a workaround until Microsoft fixes it. Do you have a plugin that works for this? – Accompanyist

@ChadDienhart don't know any. Guess Microsoft won't fix it. We'll have to use/migrate to Git. – Hellenize

@IúridosAnjos there are some tools for comparing shelvesets out there but they are clunky at best – Beichner

PLEASE check with the reviewer before you do this. It keeps any prior comments but all the locations in code are different, and the result can be incredibly hard to read and make sense of (like AzDO PR's when you dont select a specific update number). And if you do this, you will lose the original shelveset and can never get the code and comments to line up. Just submit a new review. Reviewers should be looking over each review as if it were a new thing anyway.. – Mortgage

Answer 2

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.

Stockstill

Answer 3

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.

Lunarian

Great. I will be looking forward to it too. I would welcome a real solution. My post is simply a way to work around the problem. – Accompanyist

Hopefully it's not going to look like azure DevOps pull requests. They are a spammy nightmare. – Mortgage

"This UserVoice instance is no longer available." – Uralite

Thanks for the heads-up @ruffin. Updated the answer with the new link. The issue was relocated from UserVoice into the new site. You can double check it is the exact same issue by the URL mentioned in the new page on "Migrated from". – Lunarian

Answer 4

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.

Toxicant