Resolving membership conflicts in a project or project grouping

To solve these problems, you do one or more of the following:

• Find and compare parallels, and then, if appropriate, merge them.
• Find and include changes that you requested, but that are not in your project.
• Find and exclude changes that you did not request, but that are in your project.

Use the Membership Conflicts dialog box to check for conflicts between your project members and its project update properties. Normally, you will perform this procedure after an update to see where conflicts exist. The best time to view membership conflicts is immediately after an update because the project members are up-to-date with your project update properties at that time.

Conflict Message Definitions

The following tables, and the explanation of conflict detection that follows the tables, use the following definitions:

• conflict is defined as one of the following situations:

  An object associated with a task not specified to be in your project was included.

  An object associated with a task that was specified to be in your project was not included.

  The task relationships for an object are not as expected (for example, no task or multiple tasks were associated with the object).

• explicit means directly requested; that is, included in your project update properties.
• implicit means indirectly depended upon or partially included; that is, not included in your project update properties.

Task and object relationships

A task and a set of object versions can have a relationship. You can associate a set of object versions with a task, which indicates to use those object versions together and that they depend on each others' changes. If your project includes only part of the changes associated with a task, your project build might fail, or worse, might not run correctly.

For example, if you change a function signature, you must update every other program that calls the function to have the signature change. You must either include all of those changes together in the project, or not include any of the changes.

Object history relationships

Tasks have a history relationship, but it is different from the history relationship for an object. Object history usually is numerically consecutive. Task history is a conceptual relationship only, based on its associated file history relationship. A task groups files necessary to complete a change, so the task history relationship causes a current set of changes to depend on the previous set of changes.

The main.c object has five versions. Each version is associated with a different task. (The task number associated with each version is shown under the object version.)

Rational® Synergy considers that a change to an object version contains the changes to all of its predecessor object versions. Therefore, in the example, version 3 is considered to contain the changes from versions 2 and 1.

For example, if you changed the signature of a function in version 2, then version 3, 4, and every version after would include that signature change. The changes are layered on top of each other. Even a change that removes a part of another change is layered on top of its history versions. However, the change in main.c-3 applies only to main.c-2, since the change was made to that version.

Task dependencies

Furthermore, because version 3 contains the changes from versions 1 and 2, version 3's associated tasks depend on the tasks associated with versions 1 and 2. In this example, task 58 depends on tasks 23 and 14.

Explicitly specified update properties

Consider the project myproj-sue, which contains main.c-4.

If a task is in a project grouping for the project, the project has specified explicitly to include the objects associated with that task. For example, if the myproj-sue update properties include tasks 72 and 23, then it has specified explicitly to include the object versions associated with tasks 72 and 23. In the previous figure, if the project has specified explicitly tasks 72 and 23, then it also has specified explicitly object versions main.c-4 and main.c-2.

Remember that main.c-4 contains the changes from main.c-2, and task 72 depends on task 23.

When you update a project, its explicitly specified object versions are its candidates. Update selects the most appropriate candidate, usually the newest. So in this example, myproj-sue would use tasks 72 and 23 to determine the candidate list: main.c-4 and main.c-2. It would pick main.c-4 as the newest candidate. Therefore, the project would include both the changes from main.c-4 and main.c-2. Likewise, it would contain the changes from both task 72 and task 23.

Implicitly specified update properties

Because the myproj-sue project contains main.c-4, it contains task 72, which its project update properties explicitly specified. It also depends on main.c-3, since main.c-3 is a predecessor of main.c-4. It also depends on the task that is associated with main.c-3: task 58.

However, if task 58 (and therefore, main.c-3) is not explicitly specified in the myproj-sue update properties, but the change is included anyway through its history relationship, then both the task and the object version are specified implicitly in the project. Objects associated with an implicitly specified task are not included in the project automatically.

Conflicts

Suppose that you are preparing to release your project. You specify that the release contain tasks 72 and 23, but you do not specify task 58. After your build, task 58 is included in the application. Rational Synergy can warn you that a task you did not request is included. This is called a conflict.

There are many different types of conflicts. If you had manually used main.c-5 in the project, but the project update properties did not explicitly specify task 86, and no other tasks that you had explicitly specified depended on task 86, that would be another type of conflict. Rational Synergy can warn you that it appears that an object version has been used in your project, rather than its task being explicitly specified.

Some conflicts are more serious than others.

For example, your team might decide to fix no more than one bug in a single version of a file. Further, your team requires each developer to associate only one task with each object version they change. If an object version is associated with more than one task, you must know so that you can remind the developer about the requirement. However, it is not a severe conflict, since the software you are preparing for the release contains all the changes it needs.

A more serious conflict is an implicitly included object version that is not associated with any task.

Rational Synergy can warn you about both types of conflicts.

Parallel conflicts

One of the most important types of conflict detection is detecting parallel object versions.

If your project has explicitly specified a change and it is not included, that is a serious conflict. For example, consider a situation where two parallel objects are associated with two different tasks, and both tasks are explicitly specified. In this example, assume myproj-sue contains bar.c-3. The bar.c object has the history relationships and task associations shown in the following figure.

The myproj-sue project update properties specify to include tasks 58 and 86. Your project includes only bar.c-3, which is associated with task 58. It is impossible for it also to include bar.c-2.1, which is associated with task 86, because that is a parallel branch. There is no one version of bar.c that contains both changes you have requested. This conflict is severe because a required object version is missing from your project.

Parallel conflicts can mean missing changes, but there are other types of missing changes as well.

Missing changes

Consider what would happen if you manually included bar.c-2.1 in the myproj-sue project. Changes for tasks 58 and 86 would be missing, although they were explicitly specified, because they are newer than the version of the object currently in the project.

This change is explicitly specified, but missing. You might also notice the missing changes if you looked for them in the tasks included in the project update properties. Other types of conflicts are even more difficult to detect.

If you refreshed the project update properties on myproj-sue to include tasks 86 and 36, rather than tasks 86 and 58, then ttask 58 is no longer explicitly specified. Task 86 is associated with main.c-5, and its predecessor is main.c-4, which is associated with task 72. So task 86 implicitly includes task 72. If your project includes main.c-5, it includes both changes, and everything is fine. But what about bar.c? bar.c-2.1 is specified explicitly because it is associated with task 86, and bar.c-3 is specified implicitly because it is associated with task 58 (which is implicitly included in your project). Therefore, there is again no version of bar.c that contains all of the changes that your project requested.

Large-scale conflict detection

Now consider a project with hundreds of object members, each of which has many versions in its history, and a release that comprises hundreds of tasks. No matter how careful your team is, the bigger your project, the greater the opportunity for errors. Common errors include conflicts due to parallel development (forgotten merges) or human error (forgotten object/task association). The solution is to find out about the errors and correct them before you build. Rational Synergy can detect conflicts on a large-scale project so that your team can resolve issues before they become problems (i.e., hold up the build).

Rational Synergy can detect 24 different conflicts, based on history relationships and task relationships. Other conflicts can exist, but are not severe, and they are not shown by default so users can concentrate on the conflicts that affect the software integrity. However, if you want to change the conflicts that are shown by default, your CM administrator can do so by changing the conflict_parameters model attribute.

A project is analyzed to determine whether it has any conflicts, then displays the conflicts.

Depending on the size and characteristics of your project, conflict detection can be time-consuming, so plan the best time to show conflicts. Build managers typically show conflicts after every update of a build management project. Developers might want to show conflicts if they suspect that their projects contain parallel versions or other conflicts that are causing problems.

To find a project, see Finding an object.