Today I got a notice in my Inbox to perform a peer review of some changes going into the upcoming fixpack for RTC. This was exciting to me, since I’m not on the development team anymore. Source code…cool! I figured while I’m at it I’d take the opportunity to blog about how I perform a code review. I’m not going to get into how to set up an approval process in RTC, since there seems to be plenty of other information out on jazz.net about that. Instead, let’s just focus on the actual act of verifying the changes.
In my RTC eclipse client, I open the work item being reviewed to the Links tab and go to Change Sets. The changes that have been associated with this work item will be listed here, grouped by component. I select one or more of these components, right-click, and choose Open. This opens the change sets in the Change Explorer, allowing me to view all of the plugins and files that were modified for this work item. I then double click each file to open them in the Compare Editor. This editor will show me each change, line by line, that has gone into the file. I then scroll through and review the changes.
The changes look good from a source code perspective, but now I want to actually see the changes in action. What this means is I need to get these changes loaded into my eclipse workbench so I can launch a new client or server (wherever the changes are) with the changes in it to test the new behavior. The first thing I do is make sure my RTC repository workspace is in sync with the stream where my peer will be delivering his source. I do this by loading my repository workspace if I haven’t already and accepting any incoming changes. Next, I go back to the Change Sets links in the work item and right-click, this time choosing Accept. If I have multiple repository workspaces loaded that flow to the same component I’m accepting the change sets from, I’ll be prompted to select a workspace. Otherwise, the change sets will be included in my repository workspace and loaded in my eclipse workbench. The change set will show as an outgoing change until my peer delivers to the stream. I can now test with these new changes.
If I accept the change sets without first synchronizing my repository workspace with the stream, I may be prompted when performing the Accept with a message telling me that I’m missing some of the change sets that led up to this change. At that point I have the option of applying the change as a patch. If I choose to go this route, a new patch will appear in the Pending Changes view. I will be able to then view the changes and merge them into my workspace.
This technique of accepting change sets is useful not only for code review but for collaborating with another developer on related changes. Your peer may have coded some changes you depend on that he is not yet ready to deliver to the stream. Accepting his change sets will allow you to start coding to his changes without having to wait for him to deliver.
For more information on source control and change management in Rational Team Concert, visit the Collaborative Lifecycle Management information center. The Source control overview and Sharing changes with your team topics are a good place to start.