19.5 Comparing Revisions and Resolving Conflicts
19.5.1 Comparing Revisions
Use the 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 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 .
Figure 19-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 tab to expand the view to fill Designer. Double-click the tab again to have it return to its normal size, or click the button in the lower right corner.
You can select the 
or 
buttons 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 button. If you want to compare the server version to an earlier server version, click the left-side button. When you select a different version from the History page, the top bar title changes to reflect the different copy comparisons. Click the or the 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 19-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 button in the Overview page or double-click the object in the tree view. You can also click the button 
next to the tree-view button.
Figure 19-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 button 
to return to the tree view.
When To Use Compare Revisions
There are three good reasons to use the option.
-
Finding Problems. You can use the 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 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 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 19.5, Comparing Revisions and Resolving Conflicts.
19.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 icon changes to red and Terri sees a warning message when she mouses over the icon.
Figure 19-16 Receiving a Conflict
When Terri attempts to check in, she receives an error message telling her to update before she checks in.
Figure 19-17 Conflict Message
If she clicks 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 19-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 19-19 Resolving Attribute Conflicts
Once you have made the necessary attribute changes, select .
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 19-20 Choosing What to Do with Deleted Projects
19.5.3 The Modeler View Layout In a Team-Enabled Environment
Designer 4.0 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. Note 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 19-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 19-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 19-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 19-24 Bob’s Last Check-in
For best practices, define a Modeler layout that the team can live with and leave it alone.
19.5.4 Provisioning Objects
In Designer 4.0, 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 19-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 entry, you see a node called . This is the main node under which all provisioning objects are located. and are also new nodes in the tree. System objects and unsupported objects are also visible in the Version Control view.