Automatically create shelveset for pre-commit reviews
As described in more detail here:
http://forums.devart.com/viewtopic.php?f=49&t=29267
The manual process in creating shelvesets prior to pre-commit reviews is cumbersome and potentially error prone. The in-built Visual Studio workflow manages this problem by automatically creating a shelveset from the pending changes upon creation of a pre-commit review.
It would be great if Review Assistant could provide this as an option as it would really smooth out the pre-commit review process.
We’ve implemented this feature in version 2.5.
It’s called ‘Pre-Commit Code Review Policy for TFS’
http://www.devart.com/news/2014/reviewassistant25.html
Please check it out.
-
AdminDevart (_, Devart) commented
Please, follow the link to review the functionality of Review Assistant https://docs.devart.com/review-assistant/integration-with-tfs/using-custom-check-in-policy.html. Let us know if it is a suitable solution for you.
-
Benedikt Lohmann commented
We too, are considering moving from the TFS Code Review tool with a few dozen developers. However just as with Christopher, we do not want to create a policy. We just want a simple way of shelving and adding to the revisions.
Is there any technical difficulty in doing that?
I urge you to reconsider.
-
Benedikt Lohmann commented
I can only repeat what Christopher Gerdes has said. Pre-commit-checking Policy does not solve this problem. Please consider adding a simple feature/button to shelve all pending changes automatically and add it to the Revisions.
-
Christopher Gerdes commented
I'm evaluating this product for use by our company - the lack of an ability to have a shelveset automatically created when a pre-checkin code-review is requested is the main sticking point. The TFS code review policy does not really solve this as it requires the user to request to check in code (which the user may not be ready to do).
Are there any actual plans to address this at this point in time? I see a number of posts indicating that it is an issue for others but in general the response has just been to use the TFS review policy which doesn't really satisfy the requirement.
-
Anonymous commented
Now that TFS Code Review has come down to the Professional tier of Visual Studio 2015, this is the one reason I will be moving back to TFS Code Review. It's ashame you weren't more responsive on this as it is clear that there is much less friction creating a review from the TFS code review tool.
Mandating that we have to click "Check In", in order to trigger a checkin policy is not a very good work flow. If I want to check in, I should click "check in", if I want to create a review, I should click "create review" (not check in).
-
Anonymous commented
@Devart
I believe the OP is referring to a workflow similar to the Microsoft code review in TFS, which is much simpler and has a lot less friction. A checkin policy does not solve the problem.
The workflow is pre-checkin. Having a checkin-policy for this does not make sense. The checkin policy is a good reminder and I like the addition to 2.5, but it is not the same feature that the OP is talking about.
-
AdminDevart (_, Devart) commented
Well, we think that it does cover your case. You are not mandated to run Check-in command to invoke the policy. You simply open the Pending Changed window, select changes you want to be reviewed and double-click the policy warning to create a review.
It's true that the policy does not undo local changes after shelving them.
-
Anonymous commented
@Devart
I don't think your work in 2.5 covers the use case here. The policy you describe is a check-in policy. The code hasn't even been reviewed yet, so a check-in is too far ahead in the lifecycle of a piece of work.
The Checkin policy also encourages me to start a review by clicking "Check in", when in actual fact, I do not want to check in, I want to submit a code review.
The functionality required is simply when you create a new review, to automatically create a shelf and then undo the pending changes (optional).
Whilst the TFS check in policy does touch upon that area, it is not the feature described by the OP.
thanks,