Code Review after tasks in TFS completed
Now we can perform a code review on checked in code. But my group does incremental check ins and doesn't want a code review after checking in 4 lines of code. We would like to see code reviews after say, the developer has completed a User Story task or a user story. preferrably a task.
We have a lot of investment taking place on our code review platform, including the ability to review multiple changesets. Adding this for TFVC is still on our backlog, but it is not in our 6 month plan, so we are resetting the status.
+1 to this suggestion.
It is not about how programmers should commit their changes in a single commit or not in your company so other companies must do the same. The fact is, requirement changes can happen; programmers might switch tasks; people are too busy so work items must be spread out; same feature might be changing programmers; a feature sometimes can be so bigger than 1 or 2 days; debugging, refactoring, etc.
Not only code reviews, but I think we need a tool to see all file differences of multiple changesets, therefore code reviews, or what files are modified under features or user stories, would be extremely helpful.
I think this feature is super important for code review. I mean how do you expect anyone to review changes from more than one change set otherwise? It'd be ****! And this is exactly what I'm going through currently. My developers are committing their changes at will. Once the task is complete, I need to review their changes. There should be some way for me to see a unified diff from all the relevant change sets. Until this is in place, the code review flow is useless. I mean who completes their task in one commit?
You shouldn't check in unless you are done with the task, instead use Shelvesets for intermediate checkins. Shelvesets were not that useful in older versions, but as of TFS2012 they now merge when you unshelve rather than just copying over the files, so they work more like a get latest.
Rekha Hariram commented
I just wanted to add more information to this suggestion. We follow agile and we check in frequently. We create tasks that spans from a day to 3 days. Once the task is completed by the developer it is sent for review. So we have multiple changesets to review. It is very hard to have a good picture of the changes to the same file are across multiple changesets. As of now, we are finding all the files that are affected by that task and go to "view history" of the file and pick a the most recent and the changeset before the task started to get a consolidated view of changes. This suggestion will make this process more easier. I can summarize the suggestion as :
Show changes from all changesets for a task similar to showing all changes in a changeset.
This will use a combination of existing features
1. Change history for a file – compare first and the last changeset number in a task for a file.
2. Display all affected files like for a changeset.
3. Could grey out changes from other tasks, or color code differently.
This will make reviewing a task easy instead of having to look at different changesets.
Paul Coste commented
Why not just use feature branching, allow them to check in at will, and then do a review upon integrating/merging the code. For example, they can merge down into the branch to resolve any conflicts first, commit those changes, then merge up into the parent branch and request a review on the pending changes.
Lukas Grützmacher commented
Agree! It should be possible to select multiple Changesets into one Code Review.