How to Use RTC SCM for RMC Content Development

I’ve been getting a lot of questions recently about using the SCM capabilities in Rational Team Concert (RTC) to manage Rational Method Composer (RMC) library files. The latest release of both products (RMC 7.5.1 and RTC 3.x) support Eclipse shell sharing with each other. So it’s natural to want to take advantage of RTC’s planning, change control, source control, and process enactment capabilities to support process development on RMC. And the first thing that RMC users want to leverage in this regard seems to be SCM.

This is perfectly understandable, and from my perspective desirable! And the short answer is, you can use RTC SCM to manage your RMC libraries.

BUT…

There is a philosophical gap between the way RTC manages artifacts and the way RMC wants its artifacts managed. Some planning and understanding is needed to leverage RTC SCM for RMC. And there may be some circumstances, for the moment, when it’s better to choose a different SCM system for RMC. For the record, IBM recommends using ClearCase, Synergy, CVS, or SVN to control your RMC library files.

What’s the Deal with RMC and RTC SCM?

RMC needs something resembling pessimistic locking for source control, while RTC mostly supports optimistic locking. Said another way, RMC does not support parallel development, while RTC’s SCM mechanism is designed for parallel development.

Part of the reason RMC doesn’t do parallel development (yet) is that it’s harder to do than traditional compare/merge with source code. Unlike source code like Java, RMC produces a type of XML file with a .xmi extension. It’s designed for machines to read, not humans (or even Vulcans). Sure, you can open up the .xmi file and figure out what’s going on if you look hard enough. But it’s not like it’s fun or anything.

RMC also doesn’t always keep the information you’re editing in the file you think it’s in. For instance, brief descriptions and element names are not kept in the .xmi file of the element you’re working on. They’re kept in the plugin.xmi file. This increases the complexity of performing compare/merge.

Also, just like source code, there will be times when humans need to look at the results of a compare/merge and make a decision on how to merge the text. Source code is meant to be read by humans, so this is not a big problem. RMC .xmi files are not meant to be read by humans, so it’s yucky and difficult to determine what should be kept or changed to allow the merge to happen. A visualizer or some other extra feature would need to be created to perform manual compare/merge.

Is it possible to develop an RMC feature that would show people the content in a readable way and allow them to merge it manually when necessary? And to perform automatic merges when possible? Absolutely. Just buy lots more RMC licenses and demand the feature, and they’ll get right on it! In the meantime the RMC team is focusing on other features that customers are asking for.

The fact is, while compare/merge would be desirable, the usage model of RMC makes that feature less important for process engineers than for software engineers. Many organizations only have a few people working on creating content, and the content they work on is often isolated from the other person’s work. So compare/merge is not as urgent a feature is it is for larger development teams pounding on the same code 24 hours a day.

The good news is that this common usage model can work to our advantage in leveraging RTC SCM for RMC development.

How to Use RMC with RTC SCM

Start by installing RMC 7.5.1 (or RTC 3.x) using IBM Installation Manager (IM). Then install the other product, but make sure you install it into the same location as the first product. There will be an option to do this in IM. This will put both products into the same Eclipse shell.

Launch RMC/RTC, open the Authoring perspective, and load your favorite library. Go to the Navigator view, and you can right-click on any project, select Team, and you’ll see the option to Share Project. Select that, then select the Jazz SCM option. If you’re using a Workspace library, each plug-in is considered to be its own project. If you’re using a standard library, it’s all one project and you’ll need to check in the entire library at once.

At this point you’ll have options to use existing RTC SCM components or create a new component, and you’ll be able to select a stream to deliver the component into. See the RTC documentation for an introduction to the RTC SCM capabilities.

Once you check-in and start making changes, your modifications will show up in the Pending Changes view. Here’s a look at some RMC files in the RTC Pending Changes view.

Scenarios for Avoiding Collisions

If you’re the only process engineer working on your organization’s process, if you’re the only person touching the library files, then use RTC SCM as-is with a clear conscience. You don’t have to worry about someone else modifying the file you’re working on, so you’re safe.

If you’re a small group of process engineers, perhaps 2-4 people, you can probably use RTC SCM just by placing your RMC libraries in separate RTC components, and putting those components in separate streams. Alternatively, you can place individual plug-ins into components, and assign those components to individuals. You can only do the later if you’re using workspace libraries.

In my experience, process engineers in these kinds of groups are working on different libraries or different types of content for different parts of the organization. They’re effectively a group of individuals, not a team working on the same process. So separating the content into different components and streams will isolate you as if you’re an individual process engineer as described in the first scenario.

This small group might have a core set of content that is shared by everyone. If this is the case, that content often doesn’t change much. You can put the core content into its own component, and assign only one person to modify that component. Most organizations will only find it a minor inconvenience to only have a specific person assigned to that core component.

If your group is larger or needs to modify the same plug-ins, then you’ll need to manually lock all files that you use. To be safe, you should lock all files in the plug-in that you’re editing. You should also use workspace libraries if you use this scenario. This is because a standard library shares the library.xmi file, while a workspace library maintains a separate library.xmi file for each person. It would be too inconvenient to lock the library.xmi file whenever you lock any other file.

When you lock an RTC file, it’s only locked for a specific stream (RTC components can be flowed to any number of streams). This means that others can potentially modify the contents of a component in another stream. This shouldn’t be a problem if you keep your content in a single stream. We don’t need to do the complex merging of source across streams that software development teams may need to do.

Open the plug-in from the Navigator view and lock it from there.

You can also manually lock any file via the Navigator view or the Pending Changes view. The rule here is that if you’re the slightest bit worried about someone making conflicting changes, lock the file. Just right-click and select Lock (or Unlock)

In this image, the files are locked from the Pending Changes view. Keep the locks as long as you want. In fact, I’d be reluctant to turn them off.

So there’s three ways to address almost all scenarios of method development in RTC SCM. And the simplest ones should address the needs of most process engineers. You can also mix-and-match these strategies to suit your environment, and customize the strategies in ways that work for you.

As a warning, I’ll remind you that it’s hard to merge RMC library files by hand. If you do make a mistake and two people modify the same file at the same time, the easiest thing to do is to back out one person’s change and re-enter the content when that person can get a lock on the files.

Always be aware that if you’re not manually locking files, someone could modify your content. The goal here is to set up your SCM environment to minimize that possibility and take advantage of doing content development within RTC where you get lots of goodies like SCM, work item management, project planning and tracking, etc.

I’m currently looking into an RTC extension that will automatically do enough pessimistic locking to support RMC development. More on that as it develops. Until then, enjoy using RTC SCM for RMC by taking the right approach.