Understanding Synergy Conflicts

Editor's Notes

• #3: A conflict, as defined by SYNERGY/CM, is a potential configuration problem within a project. SYNERGY/CM considers source object versions and their associated tasks together. By using this relationship and your project’s update properties, SYNERGY/CM is able to show you potential problems within your project. Detecting and resolving conflicts immediately following a update helps you avoid potential problems with your build before you actually run it! NOTE It is important to do Detect Membership Conflicts immediately following update to ensure the conflict output is consistent. Don’t worry about the details of how to actually detect and resolve conflicts here. You will get to see that elsewhere in this training class. Remember, this is just one of the steps in the build cycle.
• #4: A conflict is a potential issue with your configuration. Conflict detection is a way to check that your project contains the configuration you requested. Conflict detection identifies when only part of a change is included in your configuration. It helps ensure that if you include a particular change (as defined by a task), it includes all of the change. NOTE Remember, these are potential issues. Not every conflict is a bad thing. Whether you want to be notified about certain conflicts will depend on how your software development team works. For example, after you update your project, then perform a Detect Membership Conflicts operation, you will receive a conflict warning if you have an object that is associated with multiple tasks. If your team often rewrites a module to fix multiple problems in that module, then an object that is associated with multiple tasks will not be a problem to your organization. You can turn off such conflict notifications so that you are informed of only those that you will want to resolve. SYNERGY/CM’s conflict detection enables you to detect if your configuration is missing part of a change or includes an unexpected change. The next several sections will show you how to find some of these conflicts, what causes these potential issues, how to resolve them, if necessary, and how to tell SYNERGY/CM what type of conflicts you want to be notified about.
• #5: A conflict arises when there is a difference between the project’s update properties and the project’s members. The relationships SYNERGY/CM uses to detect conflicts include: The changes that belong together (because they are associated with a task) The changes that include other changes (because they are predecessors) The tasks you have specified to be in your project in the update properties For example, SYNERGY/CM detects a conflict when an object version is a member of your project, but is not associated with any tasks in the project’s update properties. Alternatively, SYNERGY/CM detects a conflict when an object version is associated with a task specified in your project’s update properties, but the object version is not in your project. SYNERGY/CM recommends that you update your projects immediately before detecting the conflicts for a project or projects. If a project’s update properties change after you update it or you manually update its members, conflicts will be shown for discrepancies between the project’s update properties and the project’s members. Therefore, showing a project’s conflicts immediately after reconfiguring the project minimizes the chance of additional conflicts. In the slide opposite, you can see that there is a conflict between the update properties on the right and the current project configuration on the left - the project editor-darcy does not have an associated task in the update properties. This kind of conflict could be resolved by reconfiguring the top-level project to remove or replace this editor project with a better candidate. We will see how to resolve other kinds of conflicts later in this chapter. Two primary categories of conflicts exist. These are: Changes that are in your project, but not in your update properties. For example, if you use a new object version without adding its task to your update properties, the object will show as a conflict. Changes that are in your project’s update properties, but not in your project. For example, if your project’s update properties contain two tasks that are associated with parallel versions of the same object, the version that is not a member of your project will show as a conflict. Because of the association between a task and selected object versions, SYNERGY/CM detects conflicts as a task or an individual object.
• #6: In SYNERGY/CM, an object version does not stand alone. It includes all of its predecessors’ changes; each successive version is checked out from the earlier version and is based on the contents of the earlier version. Dependency relationships is a key concept in understanding conflicts. Let’s take a look at a dependency relationship: Task 61 is dependent upon tasks 15, 27 and 56. If only task 61 is included in the project’s update properties, its changes are explicitly included, while tasks 15, 27 and 56 are implicitly included. Therefore, bar.c-4 contains not just the change from task 61, but also the changes from tasks 56, 27, and 15. Now let’s see how dependencies affect your project’s configuration. If your project contains bar.c-4, does it contain task 61? Yes. But it also contains tasks 56, 27 and 15 because bar.c-4 includes its predecessors’ changes. What if task 61 is in your project’s update properties, but task 15 is not? Then it meets the definition of a conflict: a change that is in your project, but not in your update properties. So far, the example of bar.c is one-dimensional. When you consider that each task can be associated with other object versions, dependencies become much more complex. For example, say task 56 (associated with bar.c-3) is also associated with foo.c-6. If bar.c-3 or one of its successors is included in your project, then foo.c-6 or one of its successors should also be included in your project. Furthermore, it means that the tasks associated with the predecessors of foo.c-6 are included in your project, so their other associated objects will be included, too! SYNERGY/CM analyzes all of the history and task relationships to determine which changes are included, and which should be included based on dependencies. Your project is based on another project, called its baseline. The baseline project contains all the changes to earlier versions of its member objects. SYNERGY/CM needs to look for conflicts only in the differences between the current project and the baseline project. Therefore, conflict analysis looks at each of the project’s members only as far back as the version that is in the baseline project.
• #7: A baseline is nothing more than a non-writable version of your project. It is actually any static state project used as a “starting point” for the update operation. To update your project, SYNERGY/CM uses the baseline versions plus the object versions associated with the tasks in your project’s update properties as candidates. Over the lifetime of your software development, you will change your baseline or starting point each time you begin a new release; the new baseline probably being the configuration you just released. (Remember, your new release is basically your previous release, plus any changes!) Since each object version is a composite of all the changes to earlier versions of that object, the baseline project represents a composite of all the changes to earlier versions of all of its member objects. So if the current configuration contains the baseline, then by definition, it contains all the changes before the baseline. This is important to understand because when we look at the project’s members, we must actually look at not just the current members, but the changes contained in their histories as well. The question becomes, how far back do you need to look? Well, only as far as the baseline version. In the picture opposite, if bar.c-3.1.1 is in the current project, and bar.c-2 is in the baseline, then you need to only look back as far as version 2 to analyze any conflicts! The conflicts on the following pages are shown for individual object versions. For each object version in conflict, its associated tasks (if any) are shown as well.
• #8: A conflict is a potential issue with your configuration. Conflict detection is a way to check that your project contains the configuration you requested. Conflict detection identifies when only part of a change is included in your configuration. It helps ensure that if you include a particular change (as defined by a task), it includes all of the change. NOTE Remember, these are potential issues. Not every conflict is a bad thing. Whether you want to be notified about certain conflicts will depend on how your software development team works. For example, after you update your project, then perform a Detect Membership Conflicts operation, you will receive a conflict warning if you have an object that is associated with multiple tasks. If your team often rewrites a module to fix multiple problems in that module, then an object that is associated with multiple tasks will not be a problem to your organization. You can turn off such conflict notifications so that you are informed of only those that you will want to resolve. SYNERGY/CM’s conflict detection enables you to detect if your configuration is missing part of a change or includes an unexpected change. The next several sections will show you how to find some of these conflicts, what causes these potential issues, how to resolve them, if necessary, and how to tell SYNERGY/CM what type of conflicts you want to be notified about.
• #9: GUI OPERATION: Open the project for which you want to detect conflicts. Show the project’s conflicts. From the project’s pop-up menu select Detect Membership Conflicts ... A progress indicator displays while SYNERGY/CM analyzes your project. When analysis completes, the Detect Membership Conflicts dialog displays, containing your project’s conflicts. If no conflicts are found, a message pops up indicating that no conflicts were detected. Now you are ready to resolve conflicts. CLI OPERATION: Detect Membership Conflicts for the top-level project and all subprojects in your prep project hierarchy. ccm conflicts -r project_spec The -r option specifies that conflicts will be shown recursively for all subprojects and the top-level project. If you do not want to detect conflicts for the hierarchy, do not include the recursive option. Now you are ready to resolve conflicts.
• #11: A conflict is a potential issue with your configuration. Conflict detection is a way to check that your project contains the configuration you requested. Conflict detection identifies when only part of a change is included in your configuration. It helps ensure that if you include a particular change (as defined by a task), it includes all of the change. NOTE Remember, these are potential issues. Not every conflict is a bad thing. Whether you want to be notified about certain conflicts will depend on how your software development team works. For example, after you update your project, then perform a Detect Membership Conflicts operation, you will receive a conflict warning if you have an object that is associated with multiple tasks. If your team often rewrites a module to fix multiple problems in that module, then an object that is associated with multiple tasks will not be a problem to your organization. You can turn off such conflict notifications so that you are informed of only those that you will want to resolve. SYNERGY/CM’s conflict detection enables you to detect if your configuration is missing part of a change or includes an unexpected change. The next several sections will show you how to find some of these conflicts, what causes these potential issues, how to resolve them, if necessary, and how to tell SYNERGY/CM what type of conflicts you want to be notified about.
• #12: Object explicitly specified but not included - parallel The object version is associated with a task explicitly specified in the project’s update properties, but is not included in the project. It is parallel to the currently included version and may require a merge. Since there isn’t a version which contains both the specified versions, a conflict exists. For example, foo.c-4 shows this conflict. In this example, both tasks 61 and 30 are explicitly specified in the project’s update properties, but the project contains foo.c-3.1.1. A merge is required to create a version which includes the changes of both task 61 and task 30. You could get this conflict if two developers checked in tasks with parallel versions, but forgot to merge.
• #13: Object included by use operation? The object version in conflict is not explicitly specified, not implicitly required, and the update process would not have selected it using the project’s current update properties. For example, foo.c-4 shows this conflict. In this example, foo.c-4 is a member of the current project, but its task (61) is not included in the project’s update properties. In addition, it is not implicitly required or implicitly included because another object or task is dependent upon it. This conflict could arise by manually using version 4 of foo.c. NOTE Whenever you see this conflict, you should consider whether the project was updated immediately before detecting conflicts. If not, update! If foo.c-4 should be included in the project but update does not select task 61, refer to "Troubleshooting Update Problems" in Chapter 4 to determine why task 61 is not being selected.
• #14: Object explicitly specified but not included - newer The object version is associated with a task explicitly specified in the update properties of the project, but is a successor of the currently selected version of that object. For example, bar.c-34 shows this conflict. In this example, the project includes bar.c-33, but its update properties include task 56. This might occur if you update the contents of your folder by re-running the query but not reconfiguring your project hierarchy. Alternatively, it could happen if you added task 56 to your folder manually, but forgot to update before using conflict detection.
• #15: No task associated with object The object version in conflict is included in this project, but is not associated with any task. (It cannot have been explicitly included because this would require its task to be in the project’s update properties.) For example, foo.c-3 shows this conflict. In this example, foo.c-4 is a member of the current project because task 61 is included in the update properties. Therefore foo.c-3 is implicitly included, but has no associated tasks. You can get this conflict when a developer checks out an object without a default task set, then checks the object in (still with no task associated with it), and then another developer (or the same developer) checks out a new version of the same object and associates this new object version with a task. To resolve this conflict, first check to see if any changes were actually made to foo.c-3. If it is identical to its predecessor, simply collapse foo.c-3 using the ccm collapse command. If changes were made to foo.c-3, determine which task should be associated with it, associate the task and complete the task, if appropriate. If the appropriate task does not exist, create it, associate it with foo.c-3, and complete the task. As part of the solution, you should talk to the owner of foo.c-3 to discuss why they did not follow proper procedures. You may want to customize your database to require that a default task be set before a new version of an object may be checked out or to require that a task must be associated with an object version before that object version may be checked in to a static state.
• #16: Object implicitly required but not included - newer The object version is implicitly required, but is not included in the project. It is a successor of the currently selected version of that object. For example, bar.c-34 shows this conflict. In this example, foo.c-3 is implicitly included because its successor, foo.c-4 is included in the current project. Therefore, its associated task (56), is implicitly required, and bar.c-34 is also implicitly required. SYNERGY/CM tells you that this version is newer than (i.e., a successor of) the version currently in your project. You could get this conflict by adding task 61 to your update properties without adding task 56, then reconfiguring. Alternatively, you could get this conflict if your folder was querying for “All Completed Tasks for Release 2.0” and task 61 had its release value set to 2.0, but task 56 had the incorrect release value.
• #17: Object implicitly required but not included - parallel The object version is implicitly required but not included in the project. It is parallel to the currently selected version and may require a merge. For example, foo.c-3.1.1 shows this conflict. In this example, foo.c-4 andbar.c-34 are members of the current project. Tasks 61 and 56 are included in the project’s update properties but task 30 is not. However foo.c-3.1.1 is implicitly required because bar.c-33 and therefore task 30 is implicitly included in the project. You could get this conflict by adding tasks 61 and 56 to your update properties without adding task 30, then reconfiguring. Or, you could get this conflict if your folder was querying for “All Completed Tasks for Release 2.0” and tasks 61 and 56 had the correct release values but task 30 did not. Ultimately, it indicates that a developer failed to merge a parallel version.
• #18: In order to resolve conflicts, Telelogic has a few recommendations. Remember, there are no hard and fast rules to resolving conflicts since each site has its own unique process and “software bookkeeping” method. When you are ready to resolve conflicts, keep the following recommendations in mind: Update to bring project members in sync with the update properties. If you do not understand why an object version was selected, use the verbose option on the update operation. Gather information about the conflict: Look at the project to see which version of the object is being used. Look at the object’s history to see the relationship between the object version in conflict and the object version that is being used. Look at which tasks are associated with the object versions you are interested in.
• #19: For each implicitly included or required object: Consider whether its task should be added to the project’s update properties. If it should be, find out why it is not being included already: Is the task’s release value incorrect? If this object version’s task should not be added to the project’s update properties, look at its successors, and consider whether their tasks should be removed from the project’s update properties. If they should be, find out why they were included: Are the release values set incorrectly? If you update the project’s update properties, remember to update again. For each parallel version, consider whether it needs to be merged. (If so, you can create and assign a new task.) After resolving as many conflicts as possible, run conflict detection again. Often, clearing up one conflict resolves many others, since a conflict can have a cascading effect because of dependency relationships. Remember that each site has its own unique process and method for keeping track of changes. This will impact what your site considers to be a conflict. One site might consider a specific conflict as part of their methodology, and that site would turn off that particular conflict. Another site might view that same conflict as a problem to be corrected immediately. Be sure that your site agrees on the kind of conflicts that should be addressed as early in your development process as possible. There are a total of 24 conflicts available for use in SYNERGY/CM. Of these only 15 are shown by default.
• #20: SYNERGY/CM enables you to determine which conflicts you want to be detected. Out of the 24 conflicts available, only 15 are shown by default. The conflict_parameters attribute on the base model specifies each type of conflict and whether or not conflicts of that type will display in the Show Conflicts dialog when a user requests to see conflicts for a project. You must have access to ccm_admin role to modify this attribute. # conflict_parameters (indicates whether to show each type of conflict) # <conflict_number>:TRUE|FALSE # No task associated with object 1: TRUE # Multiple tasks associated with object 2: FALSE # Implicitly included object 3: FALSE # Object included by use operation? 4: TRUE # Object implicitly required but before baseline 5: FALSE # Object implicitly required but not included - newer 6: TRUE # Object implicitly required but not included - parallel 7:TRUE # Object explicitly specified but before baseline 8: FALSE # Object explicitly specified but not included - newer 9: TRUE # Object explicitly specified but not included - parallel 10: TRUE
• #21: # Object explicitly required but no versions of object in project 11: FALSE # Object implicitly required but no versions of object in project 12: FALSE # Task implicitly included 13: TRUE # Task implicitly specified but not included 14: TRUE # Task explicitly specified but not included 15: TRUE # Task explicitly specified but none of its associated objects in project 16: FALSE # Excluded task explicitly included 17: TRUE # Excluded task implicitly included 18: TRUE # Completed fix task not included 19: TRUE # Assigned fix task not included 20: FALSE # Task fixed by this task not included 21: FALSE # Implicit task from explicit object 22: TRUE # Implicitly required by multiple tasks – newer 23: TRUE # Implicitly required by multiple tasks - parallel 24: TRUE
• #22: If a completed task is associated with an object version which contains a bug, what should you do? Should you reassign the task? No, because as soon as a task gets checked in, other users can start using its associated object versions. In order to insulate users from changes, SYNERGY/CM doesn’t let you send a task back to the task_assigned state. A completed task is like a source file that you’ve checked in; the system saves and protects it for you. Should you reject a task? No, because it’s rare that all changes associated with a task are wrong; usually you can keep some or most of the changes and just correct the parts that are wrong. For example, in the slide opposite, foo.h-1 contains no bugs and may be used by several developers in their projects. In addition, if any users have checked out from any of the files associated with the task, they already have the change in their projects and rejecting that task (or even the object versions) won’t cause the changes to be removed. Therefore we have the notion of a “fix” task. This task is created to fix a “bad” completed task and a conflict is reported if a project’s update properties contains the bad task without its associated fix task.
• #23: Usually, the first step in reworking a task is to exclude it. When you exclude a task, it goes to the “excluded” state. This means that it will not be included in any of the standard query-based folders so other users reconfiguring their projects will not get any of the object versions associated with this task. This means that they will be unable to check out new versions from these object versions and thus not inherit any of the faulty code related to the bad task. It is possible to fix a task that has not been put into the excluded state, and you might do this if you had just completed the “bad” task by mistake and wanted to fix it immediately before it could be used by others. Putting the task in the excluded state guarantees that it will not be picked up in a standard query-based folder. If you don’t exclude the task now, you can also do this when you create the “fix” task - as we will see next.
• #24: While you still have the “bad” task highlighted in the Task Browsing View: From the Views menu, select Fix... and this will display the Create Task for Fix dialog. Note that the Task Synopsis field is automatically updated to show that this task is being created to fix task 27 – the “bad” task. You can then fill out the details of this task and register it – or assign it to the developer who will fix the task. If you have not already excluded the task that you are fixing, you can do so now by checking the Exclude task being fixed toggle. If the task is already excluded, this will be deactivated, as in the slide opposite.
• #26: Finally, you complete the “bad” (now “fixed”) task so that it can be used by other users in their update properties. This will change the state of this task from excluded to completed so it will again be picked up by query-based folders at update time. There is now a relationship (called “fix”) between task 52 and task 27 – you can see this at the CLI by running: ccm relate -s -n fix which returns: task52-1:task:probtrac fix task27-1:task:probtrac If you tried to use one of these tasks in your update properties without the other, you would have a conflict. This will help you to identify when you might have included a bad task without its related “fix” task in the update properties of a project.
• #27: Completed fix task not included In this example, task 27 is explicitly specified in the project’s update properties and is in the completed state, but it has a “fix” relationship with task 52 which is also in the completed state, but is not in the update properties. The best way to resolve this kind of conflict would probably be to add task 52 to the update properties of the project and update.
• #28: Task fixed by this task not included In this example, task 27 is not in the project’s update properties, but it has a “fix” relationship with task 52 which is in the update properties. This conflict is not shown by default. If you were to display this kind of conflict, it would be because there was only one half of a task relationship in the update properties. But since it is not the “bad” task which is included, this is not displayed by default. The best way to resolve this kind of conflict would probably be to add task 27 to the update properties of the project and update.
• #29: Excluded task explicitly included In this example, task 27 is explicitly specified in the project’s update properties, but the task is in the excluded state, which means that it is in the process of being fixed. This task should be removed from the update properties, or the fix should be completed before any further work on related object versions is done. NOTE Task Reworking is discussed in greater detail in the following chapter. Only the conflicts that may be caused because of a bad task are included here to be complete.
• #30: Excluded task implicitly included In this example, task 52 is explicitly specified in the project’s update properties, but it is dependent on task 27 which is in the excluded state, which means that it is in the process of being fixed. If task 52 is the "fix" task and has been completed, then task 27 should be transitioned back to the completed state. If task 52 is not the "fix" task, then both tasks may need to be removed from the update properties and the fix should be completed before any further work on related object versions is done.