If we perform code reviews, we do that per branch. We would therefore like to see only the reviews for changes that originated in the current branch.
Userlevel 5
+4
We've added a prefilter 'Originated in current version' to the code review screen. This prefilter will become available in the upcoming 2019.1 release.
- Captain
- 63 replies
-
31 January 2019
Will this new prefilter filter on project or project_vrs? We are looking for a filter that filters all changes in the branch, not the specific version.
Userlevel 6
+4
It would be good to think about why control procedures from another branch end up in your own branch in review-status to begin with.
Best practice is to have all control procedures reviewed before they are merged to the trunk. A new branch would always start with no control procedures in review.
Best practice is to have all control procedures reviewed before they are merged to the trunk. A new branch would always start with no control procedures in review.
- Captain
- 63 replies
-
1 February 2019
Hi Anne, you are completely right that in theory this should never happen. Problem is though, that in reality, with time pressure and such, we don't really manage to keep the trunk completely free of procedures that are ready for review
"Ready for review" means: "I, as a developer, am positive this code contains no errors and can be deployed safely".
As long as that is not the case, should that version of the template be merged, or do you want to revert to the previous (reviewed) version?
A practical workaround can be to turn the statement around: "This code is being used in production, sure it is ready for review". That allows you to bulk set all control procedures to "Ready for review" at the start of a branch, with an appropriate change log description. It does mean that some old code will never get reviewed until there is a new modification of the control procedure or until those control procedures with that description are demoted to a development status.
As long as that is not the case, should that version of the template be merged, or do you want to revert to the previous (reviewed) version?
A practical workaround can be to turn the statement around: "This code is being used in production, sure it is ready for review". That allows you to bulk set all control procedures to "Ready for review" at the start of a branch, with an appropriate change log description. It does mean that some old code will never get reviewed until there is a new modification of the control procedure or until those control procedures with that description are demoted to a development status.