Code Review

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 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.

This entry was posted in Day in the Life, Rational Team Concert. Bookmark the permalink.

2 Responses to Code Review

  1. Tim Hahn says:


    This is another nice article.

    One thing to note though is that the terms you’ve used are very precise and have a very specific meaning when used in Rational Team Concert. Terms like: accept, deliver, change set, stream, patch, Pending Changes, merge, repository workspace, Change Explorer, Compare Editor. If people are not familiar with RTC’s definitions of these terms, they might want to get this background information from or the RTC online help (infocenter).

    It would be great to learn how you and others make use of repository workspaces to keep your different “developer hats” on straight. Do you use separate workspaces for what you, yourself are coding? Separate workspaces for doing code reviews? Separate workspaces for browsing code? Separate workspaces for running tests? How often do you delete your repository workspace(s)? How do you know if your repository workspace is “clean” (contains only changes that are meant for the product – nothing that is a “gee, what if I did this?” type of change)?

    • ryehle says:

      Thanks Tim. I’ve updated the post with a few references. The discussion on repository workspaces is a good one for another post, so I’ll plan on writing that up soon. I will say that I don’t use a separate/new workspace to do my code reviews. If, for example, I’m reviewing a code change for a fixpack, I’d use the same workspace that I use to do my own development work for that fixpack. That workspace is flowing to the stream where the change I’m reviewing will be delivered.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s