To solve these problems, you do one or more of the following:
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.
The following tables, and the explanation of conflict detection that follows the tables, use the following definitions:
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).
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.
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
following figure shows a version history for one object and each task
associated with the object throughout the history for the object.
The foo.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 foo.c-3 applies only to foo.c-2, since the change was made to that version.
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 foo.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 foo.c-4 and foo.c-2.
Remember that foo.c-4 contains the changes from foo.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: foo.c-4 and foo.c-2. It would pick foo.c-4 as the newest candidate. Therefore, the project would include both the changes from foo.c-4 and foo.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 foo.c-4, it contains task 72, which its project update properties explicitly specified. It also depends on foo.c-3, since foo.c-3 is a predecessor of foo.c-4. It also depends on the task that is associated with foo.c-3: task 58.
However, if task 58 (and therefore, foo.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.
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 foo.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.
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.
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 foo.c-5, and its predecessor is foo.c-4, which is associated with task 72. So task 86 implicitly includes task 72. If your project includes foo.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.