Many software projects require parallel development, where multiple teams work concurrently on different features. Configuration management (CM) systems, such as ClearCase, Rational Team Concert, or Git, facilitate this by allowing teams to isolate their work in separate areas. Different CM systems use different terminologies, but in this document we will use the term stream to denote the area in the CM system where one particular feature can be developed in isolation from other features. A stream is a distinct development branch within the CM system, dedicated to a specific feature. While the precise definition of a feature can vary, it generally refers to a group of changes performed by a certain team over a limited period of time.
A usual practice is to create feature streams that branch off a main, or release, stream. The main stream serves as the integration point for all features, and it's the source for building, testing, and releasing the end product. Unlike feature streams, which are primarily relevant to individual teams, the main stream is crucial for the entire project. It's important to maintain the integrity of the main stream by ensuring that all code builds successfully, tests pass, and the product improves continuously over time.
The following picture illustrates the main stream (to the right) and a feature stream (to the left) for a particular model file:
At version M1, the feature stream is created by branching off from the main stream. Version M1 is called the base version or common ancestor version for the feature stream. The feature is then developed in parallel with all other development activities that take place on other streams. At version F1, the feature has reached a state where it is ready to be introduced to the main stream for integration with other features. Before the development team can deliver the changes from the feature stream to the main stream they have to incorporate all changes that have arrived on the main stream since version M1. This is a merge activity which is usually called rebasing since it changes the base version for the feature stream. The result of rebasing is that the version F2 on the feature stream and the common ancestor version then becomes M2.
Note that rebasing can be done not only when the feature is ready to be delivered. Especially if it takes long time to complete the feature, it is a good idea to rebase now and then to avoid that the contents of the feature stream deviates too much from the contents on the main stream. The more different the feature stream becomes from the main stream, the more difficult will the rebasing be with a higher number of merge conflicts.
Once the rebasing is completed, the development team has to ensure that the feature still builds correctly and that all tests pass. Even if all merge conflicts were successfully resolved, there is no guarantee that the resulting model will be fully correct. This can only be verified by building and testing it. Once this has been done, and all found problems have been resolved on the feature stream, the team may try to deliver the changes to the main stream. However, new changes may have arrived on the main stream from other development teams since the point in time when the rebasing was done. If new changes are present on the main stream, another rebasing has to be done to merge these into the feature stream.
Eventually, the feature will be ready to be delivered and there are no new changes on the main stream. This is version F3 in the picture above. Now the feature may be delivered to the main stream (version M3). Note that although this is also a merge activity, it will not lead to any merge conflicts since all changes on the main stream already exist on the feature stream. Such a merge is called a trivial merge. All merges to the main stream should be trivial because as soon as new changes are introduced or there are merge conflicts to resolve during a merge, complexity rises and there is a higher risk that the model that results from the merge will fail to build or to pass all test cases. If this happens on a feature stream it is acceptable because it will only affect the team that works on that feature. But if it happens on the main stream it will affect all developers which is much worse. A main stream that has build or test failures means that
it is not advisable to branch off new feature streams since they won't originate from a stable version
rebasing from the main stream to feature streams will introduce those errors also on the feature streams
it is not possible to release the product until the problems on the main stream have been solved
The workflow described above is not at all specific for models - all files that are worked on in parallel are handled in the same way. For textual files Model RealTime includes a tool (part of Eclipse) for comparing and merging them. Compared to this text-based compare/merge tool, the following is worth noticing for the model-based Compare/Merge in Model RealTime:
Changes and merge conflicts that are reported from models are sometimes harder to understand than those you get when comparing or merging text files. The reason is that models often work on a higher abstraction level than text files. Elements in Model RealTime are described by a meta model (UML2) which uses a rather technical and abstract terminology, that in some cases are different from the terminology used when creating RT models. Descriptions of changes and conflicts may therefore require some experience to understand.
Changes and merge conflicts often depend on each other. This is because models are highly interconnected and must comply with many integrity rules in order to be well-formed. One consequence of this is that when you resolve a merge conflict, other merge conflicts may be automatically resolved as well. So a merge of models may initially seem complex with lots of merge conflicts, but once some are resolved, the situation may look much better.
Contrary to text, a model element can be presented in a number of different ways. For example in a model tree (like the Project Explorer), in a property view, in a code view or in a diagram. Depending on the kind of change different ways of presenting it may be appropriate. The Compare/Merge user interface therefore has significantly more compartments and buttons than its textual counterpart has.
When merging models Model RealTime will not allow you to edit the result model directly. If a conflict cannot be resolved by the commands that are provided by the Compare/Merge tool, you may have to take a note of the affected element's location and return there after the merge has been completed, in order to manually correct or complete that part of the merged model. Model RealTime provides a specific user interface, the Compare/Merge Tasks view, which helps you keep track of such post-merge activities.