Sample advisor: preventing multi-module change sets

It has been a while since my last post. It hasn’t been because of lack of ideas, rather time, although the blog has been bugging me in the back of my mind for attention for quite some time. So here we go … for this come back I have picked an always interesting topic, to force some rules in your SCM.

I wanted to talk about one aspect of managing change sets in Rational Team Concert. Tools like RTC and Rational Developer for z Systems come in hand with the cultural and practices changes in the umbrella of Enterprise Modernization, but let’s face it, there are certain challenges that come into play in discussions with customers quite commonly and will take some time to leave … if ever (languages used and platform peculiarities play their part as well).

In this post I am going to publish code, so our lawyers reminded me to state that the code in this post is derived from examples from as well as the RTC SDK. The usage of code from that example source code is governed by this license. Therefore this code is governed by this license. Please also remember, as stated in the disclaimer, that this code comes with lack of promise or guarantee. At the end of the post you will find the complete code solution to be downloaded.

Sample scenarios

One of these conversation common topics revolves around the management of changes in a modern SCM like RTC, particularly when it comes to some operations like:

  • Reverting a certain change: I usually hear the “what if business priority changes in the last minute and we don’t want that change in the stream anymore?”
    In my opinion there are several problems that lie behind such an statement, and we could discuss (maybe in a different post) about the processes that can be implemented in order to manage that situation, and some of them would involve business stakeholders to adhere to some practices as well.
    (I found this nice sample video of a change set reverse just in case.)
  • Promoting just one program change: work item promotion allows you to promote your changes along with the item that describes its context (e.g. business need). However, the challenge comes when there are priority changes and I need to promote just one program change but the change set contains modifications to several ones.

Both scenarios get easier to manage when the change set contains changes to just one program. So here we go with this sample advisor: the idea behind is to force the developers to adhere to a rule of one program/file per change set.

In addition to what it’s already said, and in spite of that this solution may be helpful in development environments for the distributed world as well (I’m more than happy with that), I think the “atomicity” in languages like COBOL are a real fit.

Advisor configuration options

Let’s start with the UI then to better explain the configuration.


The advisor is a “Source Control > Deliver (server)” precondition. If no special configuration is performed, it will apply to all deliver operations; however two configuration options are provided: to just check on deliveries to a certain stream and/or to just focus on certain components.

Advisor logic: checking the changes

The logic behind is pretty simple … first we (as with any other deliver precondition), check that the context of the operation is the one we care about, and from it we extract the object that carries the information about change sets in the deliver operation:

Object operationData = operation.getOperationData();
if (!(operationData instanceof IScmDeltaSource)) {
IScmDeltaSource deltaSrc = (IScmDeltaSource) operationData;

Iterable<IChangeHistoryAddOperandDelta> deltas = 

From iterating through “IChangeHistoryAddOperandDelta” elements we will be able to get handles to the change sets. I get the actual change sets from a call that resolves the work items involved, if any; not being used by now but just in case (it may help other error reporting needs):

 // not using the work items for now - 
 // may want to report about these in the future
Map<IChangeSet, List<IAuditable>> links = 
ChangeSetLinks.resolveLinks(provider, changesHandles, 
new SubProgressMonitor(monitor, 10));

Finally the actual core verification loigic basically checks if we find, within a given change set, more than one file UUID, which would mean different files in the change set:

for (IChange change : changes) 
   List<IChange> changeList = 
   fileToChanges.put(change.item().getItemId(), changeList);

if(fileToChanges.size() > 1)
   return false;

Wrap up and download

When a forbidden situation is found, the deliver action will be canceled, and the user will get an explanation like the following:


Now the developer needs to modify the change set in his workspace to be able to deliver “atomic” change sets.

You can get all the code from this link. It comes with usual lack of support, but with the hope it helps!


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