My team is using shelving for code review, for X++ code. Which is not a native visual studio language. So you can consider like we storing text files in TFS.
For code developer create a shelve and send it over to the team to reviews it and send feedback. But when the developer address the comments and generates another shelve the comments are lost.
For the reviewer，it becomes difficult if there original comments were addressed or not. The only way is compare 2 shelve code on 2 screen, which is a pain.
This function is not supported by now.
Visual Studio Team (Product Team, Microsoft) responded · March 11,2015
Thanks for the suggestion! We’re currently in the planning
process for enabling an iterative shelveset experience. We’ll update
this item when we have more details.
Source: VS UserVoice
If you just want to replace the exist shelvest（will lose comment either）, a trick way can be used: create a new shelf with the same name and then confirm "Replace shelveset"
If you want to check the old comment, I suggest you can use Email Alter in TFS. After setting it, you will get a E-mail notification including detail information of the code review. A sample as below:
Updated
Also agreed with Wouter de Kort and Vicky. The biggest advantage of code review in TFS is that you can suspend and resume your work anytime. No need to pay attention to shelvest.
Related
When using the Request Review feature in VS/TFS a shelveset is created with the proposed changes. This shelveset stays around when the review finishes, both if it is accepted and if it is rejected.
This is all fine but the review shelveset tends to dominate my list of shelvesets making it difficult to find a 'real' shelveset. Deleting the shelveset after the review has finished, seems to be bad as it is linked to the review which is linked to the final changeset.
So my question is whether there are a way of hiding these review shelvesets?
We are using Visual Studio and TFS 2015 Update 3. Here is how it looks:
There is no way of hiding these review shelvesets, unless delete them. However,
if you have deleted the corresponding CodeReview_XXXX shelveset as part of clean up activity at a later date.
Then, users go back to the same code review for some investigation, Code Review details doesn't get displayed.
If you need this feature, suggest you to add a related uservoice or vote up for below idea, this is pretty much the same thing...
TFS: Code Reviews: Shelveset based: Unable to view any details of a code review if one happens to delete corresponding code review
shelveset
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/16853590-tfs-code-reviews-shelveset-based-unable-to-view
We're using TFS for our day-to-day work management, but are currently unable to use it for source control - we're using SVN instead.
I would like to nonetheless ensure that all our work items have been code reviewed before being closed, and that any code review actions have been followed up on. Any recommendations on how we can keep track of this using TFS with minimal manual steps?
I am also concerned with ensuring that the code review step has not been skipped, and auditability of whether it has happened and whether all resulting actions were closed off. If I look at a closed task, how can I easily tell that a code review occurred on it?
(Optional) Require that every SVN change refer to a work item number in TFS with the check-in comments.
The work item in TFS has a "LINKS" tab on it. As soon as the code is checked in, another work item of type "Task" (or whatever you want to use for code reviews) should be created and linked to the primary work item on this LINKS tab to request the code review for that work item. It should refer to the SVN revision number(s) that need(s) review.
I'm not very familiar with SVN, but I assume there is a way to have branches that could be used as follows. Maintain a separate branch for reviewed code. Only code reviewers can merge into that branch. The only way code can get in there is if the proper work item in TFS exists, and a code reviewer approves and merges the code for it. I'm used to Mercurial and TFS where merging code is really easy. If merging is not easy in SVN, a different solution may be required.
If the linked task exists on a work item, then you know that the code has been checked in and code review is in process. If the link exists, and the linked work item is resolved, then you know the code review is complete. If the link does not exist, then you know that code has not been checked in for this work item (or at least it's not in the reviewed code branch, and has no intent to be there).
We have decided to edit the TFS workflow to include an extra 'In Review' state after 'Resolved'. This allows us to use the existing task board without any overhead of creating separate review tasks, or having to edit the task title to be 'in review: ....
I have a team project that contains n number of branches, and each branch contains a Database folder in the root. The database folder is where developers check in views, stored procedures, etc. We have had some issues with developers checking in SQL Code that was poorly written, introduced performance bottlenecks, and so on. The DBA has asked me to prevent developers from checking in changes to the Database folder until he has had a chance to review them.
I know that I can add a 'Database Reviewer' as part of a required check-in note, but I don't need a database review every time a developer checks in; I only need the database review to be required if the changeset contains changes to the Database folder. I haven't been able to come up with anything worthwhile on Google, so I don't think that this is functionality that is built in to TFS. Could someone point in the direction of how to resolve this, or explain how they resolved a similar problem in the past?
Thanks!
There is no clear cut solution for this, but you have a few options.
Remove the check-in permissions to the Database folder for normal developers and have them send their changes as a Shelveset to the Database guy.
Ask the developers to become more professional and have them walk by the SQL guy to review their code with them, so that they will be more proficient in SQL later (would be my preferred choice is the SQL Guy isn't part of the team)
Ask the SQL guy to join the team and have him pair with the developers when writing complex SQL scripts (that's even better).
There is no option to make the check-in note optional for specific branches, folders or files right built into the product, but by developing a custom checkin policy you could require data to be entered in the Database Reviewed field. Combine this with the Custom path policy to limit this check-in policy to specific paths in source control.
That custom policy would look something like this:
public override PolicyFailure[] Evaluate()
{
if (
PendingCheckin.CheckinNotes.CheckinNotes.Values.Any(
note => note.Name == "Database Reviewed By" && string.IsNullOrWhiteSpace(note.Value)))
{
return new PolicyFailure[]{new PolicyFailure("Database Review Required", this) };
}
else
{
return new PolicyFailure[0];
}
}
Check out this small sample project to see how you can create a custom checkin policy. And the requirements if your Check-in policy needs to support multiple Visual Studio versions.
TFS 2012 adds a Code Review feature which can be made required using a 3rd party check-in policy (again, combine with the custom path Policy to make it required only for certain paths). There are a few projects on codeplex that provide similar features for older versions of TFS. These include Team Review and TFS Review Workflow.
There isn't anything built in to handle this. I think the best way to handle it would be to lock down those folders so developers can't check in there. Create a branch/folder where you can allow the developers to check in there. This would give the DBAs the ability to review the changes before they merge/migrate them.
TFS 2012 includes a code review workflow that could also be used if you could upgrade TFS. There is also a custom add-on called Team Review that works with TFS 2008. It provides a nice workflow but it would still be voluntary.
https://teamreview.codeplex.com/releases/view/40528
Thanks,
Mike
Can I perform a code review of my peer's check-in in TFS without an explicit request?
In other words, if I've got a notification about check-in, can I make a comment after having viewed a differences if I feel like they are needed?
I cannot see such an option inside web diff view linked from a notification email. And it looks like there's no mentions about such option and/or workflow in TFS documentation.
In Visual Studio 2012, go to Source Control Explorer and view the history for an item or folder. When you see the list of changesets, right click one of them and select the 'Request Review' option
Sounds like you are after lightweight code commenting. This is available now in TFService and will be part of TFS 2013 on-premise.
Take a look at Review Assistant - an alternative code review tool to built-in one.
It's well-integrated into VS, so you won't experience a major UX shift.
It supports adding "ad-hoc" comments while browsing the code of your peers. And it's not necessary to request a review in this case.
I'm aware of the stand-alone Work Item Manager from Telerik, and an outdated project on Codeplex that doesn't work with TFS 2010.
Are there any other tools that end-users to easily enter bug-reports and have them submitted to TFS as work items? Something web-based would be preferrable, but i'd be ok with stand-alone.
WIM looks nice, but it's a little too much for end users to simply submit bugs. And they're not in TFS and don't have Team Explorer. So what other options are there?
Like John said in his comments, there is Web Access (http://mytfsserver:8080/tfs/web) which you can use to report bugs. It is even possible to let external users to create new bugs and track them without needing a CAL (license): http://msdn.microsoft.com/en-us/library/cc668124.aspx
You can give users a url that opens a new bug form and prepopulates some values for them: http://www.ewaldhofman.nl/post/2009/05/06/Initial-values-in-a-work-item.aspx
Usersnap for TFS is exactly what you need.
Add Usersnap to your web project and connect Usersnap with TFS - you will get bug screenshots directly added to your TFS tickets as attachment:
Your users don't need to login and you don't need any CALs for them.
Full disclosure: I'm CTO and Co-Founder of Usersnap.
If you have a Team Project SharePoint site associated with your TFS project, you can even use the shipped and ready to use SharePoint Product Backlog webpart that comes with the Agile process template to enter new Bugs. Very low threshold and little pre-requisites for users.