20.5 Comparing Revisions and Resolving Conflicts

20.5.1 Comparing Revisions

Use the Compare Revisions option to compare what has changed between your local copy and the latest copy on the version control server. You can compare any object that has been checked in to the version control server. Use this option to compare historical versions to your local copy, or to other historical versions.

NOTE:For the Compare Revisions option to work, you must be able to communicate with the version control server. If the version control status icon at the lower right of Designer is grey , Designer is not communicating with the version control server. Mouse over the version control status icon for further connection information.

To use the Compare Revisions option, select a project or any other object in the Version Control view and select Compare Revisions.

Figure 20-13 Comparing Revision Changes

The Compare view appears in the main editor section of Designer and is displayed as a tree with the object highlighted. The top bar indicates the object that is selected and which revisions are being compared.

Version control uses a left-to-right display of information. The left side shows local copy information and the right side shows the version from the version control server. Because there is no information in the Outline view, you can double-click the Compare view tab to expand the view to fill Designer. Double-click the Compare view tab again to have it return to its normal size, or click the Restore icon in the lower right corner.

You can select the Change left-side revision or Change right-side revision icons to view the other versions that you have saved to the version control server. For example, if you want to compare your local copy to a different version on the server, click the right-side icon. If you want to compare the server version to an earlier server version, click the left-side icon. When you select a different version from the History page, the top bar title changes to reflect the different copy comparisons. Click the Expand All or the Collapse All icon to expand/collapse all items in the Compare view.

To see a snapshot of the changes in an object, click the overview icon to the right of the object to bring up the Overview page for the selected object.

Figure 20-14 Viewing a Quick Overview of Changes

If the object you selected is made up of more than one file, you see a drop-down menu listing the files. Select a file from the menu to view the changes to that file.

To view the actual changes in more detail, click the Expand icon in the Overview page or double-click the object in the tree view. You can also click the Compare selected item icon next to the tree-view icon.

Figure 20-15 Double-click the Object To See a Detailed Description of the Changes

You can use the Next Difference/Previous Difference icons or the Next Change/Previous Change icons to move between the file’s changes. You can also click the blocks on the right side to jump to the file’s changes. After you have drilled down and have seen the differences at an object level, click the tree-view icon to return to the tree view.

When to Use Compare Revisions

There are three good reasons to use the Compare Revisions option.

  • Finding Problems. You can use the Compare Revisions option to locate when a specific problem was introduced to a project. You can determine when a change was made, who made that change, and why the change was made. If someone on your team broke a policy, you can see when it was broken, who broke it, and what their comment was when they checked it in.

  • Change Overview. You can also use the Compare Revisions option to get an overview of the changes that have been made to a project. By choosing different revisions, it is easy to see all of the changes that were made to a project in a given period of time.

  • Conflict Resolution. The Compare Revisions option can help you resolve conflicts. When you compare your local version and the latest from the server, the conflicts are highlighted in red and you can see the specific conflicts. See Section 20.5, Comparing Revisions and Resolving Conflicts.

20.5.2 Resolving Conflicts

Example 1: Checking In Changes to the Same Object

If Bob and Terri are working on a project and they both try to edit the object in the version control server at the same time, they have a conflict.

Suppose Bob checks in first. Designer is communicating with the version control server in the background and collects status information on all of the objects that are checked out. If there is a conflict, the Version Control Project Status icon changes to red and Terri sees a warning message when she mouses over the icon.

Figure 20-16 Receiving a Conflict

When Terri attempts to check in, she receives an error message telling her to update before she checks in.

Figure 20-17 Conflict Message

If she clicks OK and performs the update, version control tries to automatically merge the differences between Bob’s and Terri’s changes. However, if their changes cannot be automatically merged and Terri tries to update, she sees the Resolve Conflict page, allowing her to see the differences between her local version and the version on the version control server.

Figure 20-18 Choose Either the Local Version or the Checked-In Version

The red markers on the right side of the Resolve Conflict page show the data that is in conflict, and the blue markers show the modified local data. Terri can then choose to either keep her local version or to overwrite her local version with the one on the version control server. The Resolve Conflict page also shows the path of the file with the conflict.

Example 2: Core Model Object Conflicts

In some conflicts, the core model objects can merge manually at an attribute level, allowing you to change the attributes so that they are no longer in conflict. If the conflict is of this nature, you see the Conflict Resolution page, allowing you to manually resolve the conflicts.

Figure 20-19 Resolving Attribute Conflicts

When you have made the necessary attribute changes, select Resolve Conflict.

Example 3: Deleted Projects

If the project has been deleted from the version control server, you are given three choices: delete the local project, keep the local project as an unversioned project, or restore the project on the version control server.

Figure 20-20 Choosing What to Do with Deleted Projects

20.5.3 The Modeler View Layout In a Team-Enabled Environment

Designer handles saves by multiple users in a complex manner. Your personal Modeler view layout in a team environment changes as others change their Modeler view layout and check in their changes to the version control server. When you perform an Update from the version control server, you get the last Modeler view layout that was checked into version control. Remember that it’s just the layout that is changing and not the data.

For example, suppose Bob and Terri are working on a new project. Terri creates the project and checks the project into version control.

Figure 20-21 Terri Creates a New Project

Terri tells Bob about the new project and Bob imports the project from the version control server. Bob then adds a domain group and another driver, and checks those changes into version control.

Figure 20-22 Bob Adds Information to the Project and Checks It Back Into Version Control

During this time, Terri was working on the first driver and made only minor changes to the Modeler view, but they were enough to create local differences. When Terri saves her changes locally, then updates the project from the version control server, she sees that her Modeler view changes are merged with Bob’s Modeler view changes.

Figure 20-23 Terri’s Modeler View Changes are Merged with Bob’s

However, if Bob changes the Modeler layout again (and checks in) and Terri does not (no conflict), Terri gets Bob’s Modeler layout the next time that Terri updates from the version control server.

Figure 20-24 Bob’s Last Check-in

As a best practice, define a Modeler layout that the team can live with and leave it alone.

20.5.4 Provisioning Objects

In Designer 3.0 and above, provisioning objects such as the directory abstraction layer, Provisioning request definitions, teams, and roles, can all participate in version control. The Version Control view below illustrates how provisioning objects appear.

Figure 20-25 Provisioning Objects in the Version Control View

The Version Control view reflects provisioning objects in a slightly different hierarchy than the Outline view. Under the User Application entry, you see a node called Components. This is the main node under which all provisioning objects are located. Application Configuration and Locale Configuration are also new nodes in the tree. System objects and unsupported objects are also visible in the Version Control view.