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
Related
good morning, people!
A co-worker has made some changes to the project and now it is necessary to do the same so that I do my part now. However, he can not give a check-in because another team member "pulls" the latest version, it will pick up that part that no case could not, only I could remove those changes and after I do as the changes, yes do the standard check in.
This refeel a my doubt, should be something simple. And neither is it done the same for this not TFS. It's possible?
Your title is talking about how to share shelve with other TFS Members. There is a concert called Shelvesets in TFS. Shelvesets are useful when you want to stop work for:
Collaboration: You have pending changes that are not ready for check
in but you need to share them with another team member.
Other peoples could share their pending changes(haven't checked in) to you through shelveset. You could unshelve his shelveset which restores shelved file revisions, check-in notes, comments, and work item associations to the current workspace.
If you don't want the shelveset mess up your local work in VS, please also take a look at my reply here: Undo TFS Unshelve
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.
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: ....
Every time I've coded a new feature (about once a day), I create a shelve set containing my changes and request a code review of my team lead (of the changes in the shelve set). He's pretty busy and it takes him half a day to a day to do the review. Meanwhile, I've continued coding the next feature, on top of the changes that I asked him to review.
My problem is: How do I then check in the changes that he approved, but not the (unreviewed) changes that I made after I created the shelve set?
As MrHinsh says you need to park what your working on and progress the code review check in and then return to what you are doing.
If you are using the the TFS code review then you will be using VS Premium or above, you can therefore use the My work tab to handle this process for you. You can Suspend what you are working on, revert back to your reviewed code, and when that is completed you can then restart the work that you were on.
TFS will shelve your changes and work items for the Suspend, when you then restart the work all of the source and work items will be restored back to the IDE and the IDE will revert back to the state it was in when you paused.
Information on the My Work can be found http://msdn.microsoft.com/en-gb/library/hh543900.aspx
There are really two main options for this:
You can shelve your new changes and revert. Then retrieve the shelve for the review and checkin. Then retrieve the new work.
You can have a seperate workspace that you keep clean of new development for checking in the reviews. Switch to it, get latest, and retrieve the reviewed code. Then check in.
Our development process works like this: Every 2 weeks the team lead (me) goes in and reviews everyone's changesets to make sure they are up to the coding standards. I would like to use TFS 2012 to help automate this process.
There are 2 problems with this:
There is no way to submit an unsolicited code review. I can live without this if necessary, I guess
There is no way to associate a code review with more than one changeset. This is a deal-breaker
I read one article which said it's possible to link changesets to a work item after the fact and when I open the work item for the request review I do see the Links tab. However, when I click "New" or "Link to...", there is no option to link to a changeset. There is only an option to link to each work item type in the process.
Does anybody know how to do this? Are there any plans to add these features to TFS?
Here's a screenshot:
Unsolicited, no.
You can rightclick a changset in the history screen to request a review post checkin.
And there is a nasty workaround to get what you want to achieve. Check out all files you want to review and request a review. You can then undo your checkout, the shelveset and the review request will remain.
Alternatively you can just go to the source control tab and do a checkout-all on the rootfolder of your solution, request the review, undo your checkout and do the review.
As for linking changesets to a Work Item, this can be done post checkin. Open the work item, go to the links tab and click "Link to..." The dropdown there will have a "Changeset" option. But I don't think this link type is enabled for Code Review Requests, since these use a Shelveset and not a set of changesets as the source for the code to review.
I expect you could use the TFS API to generate a shelveset with all the changes from a specific developer in a given timerange, put these on a shelveset and request a review on that. But no existing feature to do that exists.
Or you might be able to edit the shelveset of associated to the review by creating a new one with the same name.
An alternative approach:
1) at the beginning of the two week cycle, initiate the code review process and note the work item number that is created. Simply request a review from yourself with no code changes at first.
2) Have all your developers associate their check ins for the next 2 weeks with that work item #
3) When you are ready to perform the review, simply open the work item and go through the changesets.
That should accomplish what you want.
Option #3
[I'm assuming here that the changesets that your are trying to associate to a single code review are consecutive, for example 20001:20010]
I "roll[ed] back to a specific changeset" (in my example above
20001). I check it in the changes. The code is now in its original
state.
Then, I "roll[ed] back to a specific changeset" (in my example above
20010) and check it in again. The code is now in its final state.
Finally, I request a review on the latest revision. This review
compares the latest two commits - the ones I created from the
rollback.
As a bonus you can compare specific changesets in the history page. You can use this compare to make sure that the commits above did in fact revert the code to revision 20001 and 20010.
On item #2, I have a standard work around that you might like to combine all changes from many changesets into one shelveset for review. I tried the checkout method mentioned above and ran into issues, partly because my review had 25 files or so and after checking them out, if I refreshed, TFS removed them from pending changes because it TFS's opinion there were no changes.
First, (assuming that your changes are already checked in, and in multiple changesets), have a workspace with the latest files on a disk path such as D:\Latest...
Create a new "local" workspace (called "Review"), map the same project to the slightly different path (say, D:\Review...") get all the files. Go to the history of that project and just before your earliest changeset, right-click and select "Get this version".
At this point, go to the history and rollback any changesets that someone else may have changed in the meantime, if any, that you don't want to be part of the review, unless someone changed a common file. Leave those.
Using beyond compare, compare "D:\Latest..." to "D:\Review...", copy your changes from Latest to Review. Go into the common files and copy only the lines that you want reviewed. When Beyond Compare writes out the changes, TFS will detect the change and put the file you save in your pending changes list for the "Review" workspace. (That's a feature of local workspaces.)
At this point, you just shelve your pending changes from the "Review" workspace, and request a review on that shelveset.