Hello. Today, we're going to take a look at code reviews within Surround SCM. Code reviews provide a way to group a set of files and changes and gather feedback from other users. Surround SCM code review functionality allows you to do this without having to mail files around, gather everyone in a room, or have people mark up the actual files. Code reviews work with all kinds of files but are especially convenient for text files where Surround can show detailed differences between versions.
First, let's look at the code review window. Code reviews are grouped by mainline and the window defaults to only showing you your unapproved reviews. There are also several other built-in filters or you can create your own. Code reviews follow a simple workflow. They start out in the work in progress state, which is when you are still adding files and versions to a code review and haven't asked for feedback.
Once you start the review, the code review moves to the awaiting review state. Once all your reviewers have completed the review, it will either move to the approved state, if there are no unaddressed comments, or to the needs attention state, if the reviewers have left comments for you to look at.
Let's start by making a new review. There are a couple of ways to create a code review. The first is here in the code review window. After clicking the "Create Review" button, I’m prompted for a review name and I can optionally enter any notes about the review. I can also specify the reviewers now, as well as any other authors. This approach works well if you follow a process where you create a code review for each new feature or managers organize reviews.
Once a code review is created, you can start adding files to it. The easiest way to do this is during the normal course of working with files in Surround.
You can add a file to the code review during check in, when adding files, when promoting files, or when committing change lists. You can also add files from the main file list as well as from the history dialogue. When adding files, you can either add the whole file or any changes between specific versions. Let's add two files to our code review. First, I'm going to check in the changes for WysiMain.cs. Next, I'm going to add Program.cs to the code review as well.
Since I added WysiMain.cs from the check in dialogue, the changes from that check in will be highlighted. Program.cs was added with no specific version chosen, so the whole file was added and no changes will be highlighted for reviewers. Once you have a code review set up with the files you want, it's time to start the review. You must pick at least one reviewer. When you start the review, all reviewers will be sent an email letting them know it's time to start. The code review automatically goes to the awaiting review state.
I'm going to log in as one of the reviewers to see their view. Each reviewer can open the review and start looking at changes. If they have any comments, they can just select the part of the files they have input on and choose "Add Comment." Once they finished reviewing a file, they click the completed checkbox. If any files have comments associated with them, the code review is marked as needs attention.
The author can mark each comment as addressed as they work on it. Once all reviewers' comments have been addressed, the code review can be sent out for final review and approval. There's also a way to do a quick ad-hoc review. Select a file and choose "Review File." This opens the file, allowing you to review its contents. If everything looks good, you can close your review and everything is finished. If you see anything that requires comments, just add a note and create a new code review on the fly.
Finally, you can easily check whether a file has any unaddressed comments by choosing "View Unaddressed Comments." This will look across all branches to see if the version of the file in this branch has lines which have comments associated with it. I hope you found this brief introduction to code reviews helpful.