Check in code from Code review in TFS after approval

Question

I would like to check in code after a code review is approved. I came across this stack about creating code reviews and checking in, but my question is a little different.

My issue is that I want to create a code review; however, I do not want to check in the code until it is approved. That limits me from being able to start another code review with removing related work items. What I would like to do is create code reviews and check in from the code review tab in the Team Explorer

Is that possible? It is the same principle as creating a code review after the check in, but with Code reviews and checking in. I do not want to go to pending changes and check in there because I may have removed the related items. But I do want a check in to be tied to my code review.

Otic

Well, you need to have your code accessible to the reviewer, so the code will need to be checked in somewhere. My suggestion is to have your development branch, check in your code and have it reviewed. Then either make the necessary changes or roll your changes back. This is also good for tracking everything done - your work, the reviewers work, and then, if needed, your revisions from the reviewer comments. – Alienate

The only problem is that I need to have the trunk based development for DevOps structure and thus cannot have my own feature branch to work on. Once it is checked in it goes all the way to my testing evnironment – Otic

I don't see why that should mean you can't use short-lived branches. As a matter of fact, I would think it would be preferred to do your task/work-cycle within a branch that represents a self-contained dialog between yourself and your reviewer, all of which will be carried into your mainline when you do your merge after your final clean review. You are going to have to check your code in, regardless, for your reviewer. For one, because s/he must get your code somehow, and two, the review information needs to be a part of your actual check-in. – Alienate

I do see what you're saying. With the TFS though they can look at the suggested changes without having to get the code checked in. Ultimately, I am wanting to tie the review with the check in. but do it from the code review side of things once it is approved. Instead of checking in immediately because I may have to rewrite the entire code base perhaps based on code review suggestions. – Otic

Which, again, is a perfect reason for having it all in a "dev cycle" branch. It, even with no other good reason, minimizes the clutter of multiple check-ins. Visually in TFS it would be a collapsed node instead of, in a bad case scenario, having 10+ check-ins for minor changes or roll-backs. That information would all still be there, but it would be collapsible. Plus, if you are doing automated tests/builds/deployments, you wouldn't trigger that cycle every time you made a minor change. – Alienate

I wish we could change the strucutre to incorporate a 'local' branch, but I cannot change the structure of our branching methods. So working with what I have, is there a way to do what I want? Or is this a limitation to TFS based on how I am using it? – Otic

Answer 1

Okay, so for documentation purposes. I did not fully understand the shelving that TFS allow me to do. After reading Shelve and Unshelve Pending Changes, it makes more sense to me. I can shelve what I am working on, unshelve the code that I have done a code review for, then check in that code. That way I can create a code review and continue working until that code review is approved. Once approved, I can go unshelve the changes and check it in.

Otic

Answer 2

Unfortunately, there is no "proper" way to do what you are trying to do. You could have your working directory on a shared drive and just notify your reviewer when you are ready for them to start their review process, but that side-steps the accountability by not having each development/review iteration officially logged within TFS. This means you should check in your work and let the reviewer do their job, then continue on in that fashion to make any changes requested by the reviewer, check in, and get another code-review.

For completeness I will mention my suggestion from my comments here as well.

My suggestion would be to create a self-contained, short-lived development branch where you will do your development and have your code reviewed. Then once the development and reviewing has been completed to satisfaction, that branch can be merged back up and destroyed. This provides a much cleaner and safer approach. 1) It reduces the clutter in the history within TFS. 2) It prevents multiple unnecessary automated builds/tests/etc... from being triggered.

In your comment you suggest that this changes the "structure of your branching methods". I don't see how doing this changes anything in any way that matters. Your merge would be just like your final development check-in except that by this time all reviews have been completed and you are performing a single, clean check-in. It will still contain all of your check-in and review information, however instead of a cluttered chain of check-ins, you will have a single collapsed node which contains every single thing that was done for that particular task.

I would check with your manager, your code reviewer and/or anyone you have that is in charge of TFS and creating/maintaining your TFS policy. This approach really doesn't change anything in regard to how the rest of your process works. You would have simply abstracted your development cycle to a self-contained environment. The second you perform your merge you are right back into your normal process as you have it now.

Alienate

What I am asking would not be a work around. Ultimately it would tie the code review to the check in, but would only check in once the code review is complete. Once complete, I could check in from the code review tab is what I am wanting. – Otic