TFS code review should not require a new code review to be started when code that is already under review is changed based on review comment
Migrated from Azure DevOps UserVoice forum
It seems that TFS requires a new code review to be started whenever code that is already under review is updated in response to review comments. It is not only unnecessary busy work for a developer to initiate a new review each time a review comment would suggest a change to the code that is already under review is necessary, but it also prevents having a single picture of changes made as a result of the review process.
With the current method, a single logical code review may span multiple physical code reviews and the comments for the single logical review are fragmented across several physical reviews.
Add Comment
Isn't this implemented now? You just push the update to the same branch and it appears in the existing Pull Request.
A code review is tied to the change set. When you check in a fix, it is a new change set so you cannot see any review notes associated with the fix. You can make comments back and forth in a review cycle, but as soon as the fix is checked in you have to start a new review on the fixed change set. Makes it a pain if you do lots of reviews as you have no context as to what you asked the developer to fix.
Hmmm, it doesn't work like that on VSTS/Azure DevOps (i.e. the on-line version) using Git. The Pull Request is linked to the branch, each set of commits to that branch comes in as a new update and all previous review comments are all there.
More specifically, if a pull request is set to "Wait for author" then there is no way within the tool for the developer to indicate that they have completed their changes and the PR is ready for re-review. The documentation indicates that this has to rely on communication outside the tool ("The author should let you know when you should re-review the code after they have addressed your concerns".).