Rational Team Concert (RTC) has started releasing quarterly. Since large features rarely fit into such short cycles, we’re making heavy use of RTC’s branching and merging functionality. That could result in merge hell, but it doesn’t. This post will give you an idea of how the RTC team uses our own source control management system, and show how its design helps large teams maintain many branches without nightmarish merging.

I’ve been working on the RTC Source Control Management (SCM) team for the last seven years. As such, I’m going to use the RTC term stream to refer to branches. Similarly, my explanation of the stream hierarchy will focus on the RTC and SCM streams:

1. The product integration stream is at the top of our hierarchy. Changes from every RTC team are eventually delivered here and each RTC team accepts changes from here. We use this stream to build the zips and installers on the jazz.net website.
2. The SCM team has its own integration stream. Bugs are fixed directly in this stream, and it’s used to stage features and incoming changes from the product integration stream. Every other team in RTC has a similar stream (e.g. Build and Work Items).
3. Individual SCM feature teams have their own streams that accept from SCM integration, but don’t deliver there until the feature is complete.

Flows near the RTC Source Control stream

In our model, the SCM bug fix teams and feature teams will likely modify the same source files. On rare occasions, top-level teams will also accept changes to their code from other teams.

This could result in merge hell: changes are flowing up and down the tree, multiple users modifying the same files, and teams have different release cycles. But it doesn’t. Thanks to the design of RTC SCM, merges are easy.

Much of the ease-of-use comes from our notion of change sets. RTC SCM is change set oriented, meaning that developers group their changes together and flow them between streams in a coherent unit. They allow us to avoid pitfalls faced by file-oriented systems: failing to flow all changes between branches, and obfuscating ‘annotate’ output with patches.

Annotation of ScmService, showing author and line number. The coloured left column shows the name of the developer who last touched the line in question. The History View (not shown) indicates the change set containing the change.

When the inevitable happens and there’s a conflict within a file, special merge changes are generated. Merge changes allows us to fiddle with the content of a file so it’s (hopefully) correct and mark the ancestors of the change. The ancestors are useful to know in case problems occur and we need to revisit the content merge. And they also make it possible to show pretty merge graphs:

Merge graph showing the history of ScmService.java. For more information on reading merge graphs, see Practicing source control archaeology with Rational Team Concert.

Since our change sets are linked to work items, it’s easy to see a human-meaningful explanation of each change set. Work items also allow us to group change sets into a logical task, so whoever is tasked with merging changes can get an idea of the intent behind the code modifications.

The Pending Changes view grouping changes by work item. Two work items are shown (263952 and 266769) with a number of change sets in each.

RTC hasn’t solved all of the problems in source code management: when multiple developers modify the same region in a file, someone has to understand the changes and merge the conflicting lines. But we’ve designed a system that does a great job at handling the average case of branching and merging for different teams.

In my future posts I’ll take you on a tour of the tools that help us with branching and merging, controlling what can be delivered, promotion builds, annotation, and external compare tools.