Using RBTools with HCL VersionVault and IBM ClearCase¶
This guide covers the various ways to use RBTools with HCL VersionVault or IBM ClearCase. You can post changes using both Base ClearCase or UCM workflows.
A typical workflow looks like this:
Step 1: Create your change¶
You’ll be able to post a branch, label, activity, baseline, or stream representing the change you want to review.
Step 2: Posting changes for review¶
Posting checked-out files¶
The most simple case is posting a diff of all currently checked out files in your view. This will work no matter what workflow you are using:
$ rbt post
Posting changes with Base ClearCase workflows¶
When using Base ClearCase, there are several ways you can post code for review.
To post a change between a branch and its predecessor, use:
$ rbt post brtype:branchname
To post a change between a label and its predecessor, use:
$ rbt post lbtype:labelname
A diff between two labels can also be posted. This requires posting from within a dynamic view:
$ rbt post lbtype:label1 lbtype:label2
Posting changes with UCM workflows¶
If you’re using UCM, you can also post activities, baselines, and streams.
To post an activity, use:
$ rbt post activity:my-activity
To post the diff between a baseline and its predecessor, use:
$ rbt post baseline:project-dev
To post the diff between two baselines:
$ rbt post baseline:project-integration baseline:project-dev
To post a stream:
$ rbt post stream:dev-stream
Posting files manually¶
Finally, you can also assemble a diff using file@revision pairs. This requires
posting from within a dynamic view. Each argument will be a
file@@revision1:file@@revision2 pair:
$ rbt post /vobs/proj/file.c@@/main/0:/vobs/proj/file.c@@/main/1
Multiple files can be posted by adding additional file/revision pairs:
$ rbt post /vobs/proj/file.c@@/main/0:/vobs/proj/file.c@@/main/1 \
/vobs/proj/file.h@@/main/0:/vobs/proj/file.h@@/main/1
Once you’ve posted…¶
Your changes are now posted to Review Board, but are in a draft state. Nobody can see it until you’re ready to publish.
You’ll now need to go to the URL and fill out the Summary, Description, or any other fields.
If you have default reviewers set up, they’ll be assigned automatically, but you can also specify the people or groups you want to review your change.
Once you’re done filling out fields on the review request, click Publish to send it out for review.
Step 3: Update from reviewer feedback and re-post¶
Got some reviewer feedback to incorporate into your change? Easy.
Depending on your workflow, make any changes as necessary. For example, continue to edit your existing checked-out files, or add additional changes to your activity.
Update the review request with the latest code, using
rbt post -r <review_request_id>. This option can be used with any of the diff selection methods listed above.For example:
$ rbt post -r 123 activity:my-activity Review request #123 posted. https://reviewboard.example.com/r/123/ https://reviewboard.example.com/r/123/diff/
Update any information on the review request, if you want to.
We recommend describing the changes you’ve made, so reviewers know what to look for. The field for this is on the green draft banner.
Publish the new changes for review.
Rinse and repeat until the review process is complete and the change is accepted.
Step 4: Finish your code¶
Depending on what workflow you’re doing, you can now proceed to finish the code change. This could involve checking in any checked-out files, or delivering your current UCM activity.
Step 5: Close your review request¶
Now that your change is in, it’s time to close your review request. You can do this in one of two ways:
Navigate to the review request and close it.
In Review Board 6 and newer, click Close -> Completed.
In Review Board 5 and older, click Close -> Submitted.
Run rbt close <review request ID> (see the documentation).
Putting it all together¶
Let’s walk through an example using a UCM activity.
Posting your change¶
First we’ll create our activity and edit some files.
$ cleartool mkactivity -nc my-activity
$ cleartool checkout -nc foo.py
$ vim foo.py
$ cleartool checkin -c "Make initial change" foo.py
$ cleartool checkout -nc bar.py
$ vim bar.py
$ cleartool checkin -c "Make initial change" bar.py
Now let’s post these changes for review.
$ rbt post activity:my-activity
Review request #1001 posted.
https://reviewboard.example.com/r/1001/
https://reviewboard.example.com/r/1001/diff/
At this point, we’ll publish the review request, and then wait for feedback.
Update from review feedback¶
Hey, we got some review feedback. Let’s make changes to our code, and then update our review request:
$ cleartool checkout -nc foo.py
$ vim foo.py
$ cleartool checkin -c "Update for review feedback" foo.py
$ rbt post -r 1001 activity:my-activity
Review request #1001 posted.
https://reviewboard.example.com/r/1001/
https://reviewboard.example.com/r/1001/diff/
Go to the review request, describe the changes you made, and publish the new changes.
Finish up¶
Once you’ve gotten approval (reviews with a “Ship It!” that match your department/company’s policies), you can complete your change and close the review request.
$ cleartool deliver -activities my-activity
$ rbt close 1001
(You can also close it in the review request page.)