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
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.
We have a lot of investment taking place on our code review platform that will enable iterative code reviews, and we will initially bring that functionality to Git (via pull requests). Improving iterative code reviews for TFVC is still on our backlog, but it is not in our 6 month plan, so we are resetting the status.
Sina Jazayeri commented
The problem with reviewing shelvesets is lack of traceability as shelvesets can be deleted at any time. This is problem if you have to show review of code for audit/process requirements.
Taken from a different source:
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
Andrew Stanton commented
@Visual Studio Tea - Git is stupidly dangerous. I don't want to have the ability to "whoops" an entire source control history. The point of having version control is so I don't lose changes.
The only time I need to use the "powerful" features of Git is to unfuck myself when I was trying to do things that should be brainless and missed some convoluted `--i -o --git-******` switch or vim command resulting in an "oh ****" moment.
Programming well is hard enough. Stop pandering to that ****** source control before your own, unless you are going to fix it's deficiencies.
Sina Jazayeri commented
For those waiting, we gave up waiting and invested in Smatbear Collaborater which offers iterative changes and integrates well with TFS. It's clear TFVC is no longer treated as high priority by MS.
This is so pathetic, you need to implement this immediately. We have been waiting forever.
Sascha Kolb commented
Whats the status on this ?
Doug Waterfield commented
I have recently begun leading a team that has been using TFSVC for a while. I'm really surprised that such a basic workflow isn't available!
When will this be in the product?
Michael Denholm commented
Considering its now 15 months later and a new version of TFS recently released, should I assume this will never be implemented in TFVC, give up on it and move to Git?
Computing Mastery commented
You are too late! Who in their right mind will use a CR tool that requires a new CR to be started after reflecting even a single comment ???
Rob Siklos commented
@Andrew Ch: This is not a a reliable of doing things. The problem is that as the comments get addressed, the line numbers change, and you complete lose sight of what the original code review captured.
@80's Rocker: Couldn't agree more, but the writing is clearly on the wall - TFSVC is dead, and too bad for all of us that are using it. I guess we're just expected to migrate to Git or stay with TFSVC and live with a reduced feature set. I wish they'd just come right out and say this. At the end of the day, it seems the mob has spoken and Git is the winner.
80's Rocker commented
This is really sad that it on 1/15/16 this was still not on the roadmap to be implemented. Greate feature is being killed by poor implementation and not fixing a glaring feature shortcoming in a timeley mannner. The VS team obviosly uses GIT and that is why getting this implemented in GIT was a big priority instead of TFS. But by doing that they are ignoring a very big user base of TFS who don'want to switch over to GIT.
Jason Tremper commented
As an ex-microsoftie: PLEASE MAKE CODEFLOW PUBLICLY AVAILABLE :)
Andrew Ch commented
There seems to be a way of doing this already -- if you make your changes in response to the code review, and then save the changes back to the shelveset (set the name to the same name of the shelve set used for the code review).
This is a problem for our team.
I agree with Joshua, moving to git is just not an option for us at this point. We have many in house build process(es) built on top of tfs vc. This really needs to be planned and implemented and not just abandoned for git.
Brendan H. commented
Just a comment that this is working well for us now using TFS Git on premise! We do not use TFVC.
Joshua Drake commented
Abandoning your own products for Git seems to be a self-defeating strategy.
Vito DeCarlo commented
I agree. I'm not against git, but if that's where everything is heading, I'd just assume migrate now and get it over with.
Am I reading this right? That this is being done for Git, but not TFVC?
If so, I am a bit concerned. I did not believe the "TFVC is dying" statements. But if this is being done for Git and is not even road-mapped for TFVC, well that looks bad.
Makes it looks as if TFVC is a "second class" member of the team. At best.