Using TFS/TFVC's Code Review feature it will automatically create a shelfset for you for others to review your changes. By default it creates a shelfset named "CodeReview_xxx". If you need to update your code as part of the review process you will need to pull down & edit the shelfset by name. It would be handy if I could name the shelfset the code review is going to use instead of the auto-generated name but I don't see a way to do that.
There is no way to name the shelveset that Code Review generates automatically. You could try to create the shelveset first and then request review. In this way, you can name the shelveset. Check the screenshots below:
Related
I would to trigger a build if and only if inside the comment related to the check-in a given keyword appear (e.g: {{start-a-build}}). So for instance:
changeset 1: Initial Commit
changeset 2: Bug fixing
changeset 3: {{start-a-build}} First release
So at the first two checkins nothing happen. But as soon changeset 3 is detected, TC will read the changeset comment and since the {{start-a-build}} keyword a new build will be started.
Is this possible? Is this smart? What could be a better approach?
I use TeamCity 10.0.4.
TFS provides a default check-in policy named Changeset comments policy, this policy will require users to provide check-in comments. But there is no rule to require comments that include a specific text.
So you can create your own custom check-in policy to check whether the check-in comment include specific texts and call TFS build API to queue a build. Check out this link for an example of how to do this, as well as this blog.
Please notice, if your OS is 64-bit, you must add the checkin policy under the Wow6432Node instead of the path stated on MSDN:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\xx.0\TeamFoundation\SourceControl\Checkin Policies
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'm in a company now that forces TFS upon us. I have used Git all my life, and I am struggling to find some features I am used to in TFS. For example, I'd like to make small commits locally and push them up later together. This way I can keep track of my changes and roll back if I ever need to. Is there a way to do this in TFS?
What you're looking for is called "shelvesets" within TFS.
This link explains how to create one:
MSDN on how to create a shelveset
To shelve folders and files from Solution Explorer
In Solution Explorer, right-click, and then click Shelve Pending Changes.
In the Shelve - Source Files dialog box, type the shelveset name (for example, shelvetest) in the Shelveset name box.
The Shelve - Source Files dialog box includes two options:
Preserve pending change locally
By default, this option is selected. When this option is selected, the changes you made to the files or folders in your local workspace are preserved.
Evaluate Policies and check-in notes before shelving
When this option is selected, all check-in policies are evaluated before the shelveset is created. For more information, see Set and Enforce Quality Gates.
In the Comment box, type Testing my shelveset, and then click Shelve.
The files and folders are copied to the version control server and are available for other team members to unshelve.
And this link provides some background about using shelvesets:
MSDN on reasons to use a shelveset
For a variety of reasons, sometimes you need to set aside some or all of your work in progress. Shelvesets are useful when you want to stop work for:
Interruption: You have pending changes that are not ready for check in, but you need to work on a different task.
Collaboration: You have pending changes that are not ready for check in but you need to share them with another team member.
Code Review: You want another team member to perform a code review of your pending changes.
Private Build: Before you check in your changes, you can use your automated build system to build and test your code.
Backup: You have work in progress that you cannot finish now so you want a backup copy that is stored on your server and available to other team members who might need to access it.
Handoff: You have work in progress that you want to hand off to another team member.
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.