Integration Lesson 1 – Full Integration

In this first lesson, we will perform a full integration of a trunk and branch module.

Navigate to the project for this lesson, and open its module in Exclusive Edit mode.
To begin a full integration, choose the Configuration Mgt > Integration menu option.
Here we see the first dialog box of the integration process. For a description of the Start Integration GUI parts, please consult the Branch Manager User Manual. Press the Browse button to select the source of changes to integrate into this project’s module.
Select this lesson group’s Trunk project. This was the project that was originally branched for this lesson. Then press the OK button.
The script will automatically find the parallel module and calculate the common base. At this point you can choose another source version for the changes to integrate by pressing the Choose button; however we will use the current for this lesson. Since there are no Integration Baselines yet, leave the Compare with Common Base radio button selected. Press the Start Integration button.
Since we are using the current version of the source module, the script will warn that a baseline will need to be created in the source module after finalizing the integration. Press the Confirm button to continue.
Next we must select the aspects to integrate from the source to our lesson’s target. Check the Select Common checkbox.
We want to include Test Status attribute as well, so check the Test Status attribute in the list. Then press the OK button.
This brings us to the Integration of Module dialog box of the integration process. For a description of the Integration of Module GUI parts, please consult the Branch Manager User Manual.

If you look back at the module we opened in Exclusive Edit (i.e. the Target), you will see that new columns were created in the current view. These columns help the user understand what has been changed per object in the source and target compared to their base.
In order to best understand how the changes are presented, we will open the source and base modules. You could use the open module buttons near the top of the GUI, but there is a quicker way: double-click on a change and the modules will be opened and the objects selected. Try this by double-clicking on the Non Conflicted Change of object ORG_17.
With the source and base modules/baselines open, we can begin a thorough examination of the change. First, look at the base module/baseline (/4.0 Trunk for Username/Module baseline 0.4). For object 17, we see that there is an out-link.
Next look at the source module (/4.0 Trunk for Username/Module current). For object 17, we see there is no out-link, i.e. since the common baseline of the source and target modules, a change has been made to the source.
Now look at the target module (/4.1 Full Integration for Username/Module current). ). For object 17, we see that there is an out-link, i.e. since the common baseline of the source and target modules, no change has been made to the target object (at least in terms of out-links).

These facts are laid out in the integration columns in the target module. The column called Source Changes says a link has been deleted, i.e. since the base a link was deleted in the source’s object. The column called Target Changes is blank, i.e. no change has been made to the target’s object since the base.
Turn your attention back to the Integration of Module GUI. You see that there is one change listed for ORG_17, a Link Deletion. In the Changes in Source Module text box on the right-hand side of the GUI, the same text as the Source Changes column is shown.

Thus, we know that the source module has changed since the common baseline: a link in ORG_17 was deleted. We also know that our target module’s ORG_17 did not change.
Let’s look at another object. Look back at the base module/baseline, object ORG_16. We see that it has an out-link. Then look the source module, and notice that ORG_16 also has an out-link, i.e. it’s links have not changed. Next look at ORG_16 in the target module. We see that there is no out-link, and the text in the Target Changes column reflects that; it says an out-link has been deleted.
But if you look at the Integration of Module GUI, there is no object ORG_16 listed (if it were, it would be between ORG_12 and ORG_17). Object ORG_16 isn’t listed because the list only shows the changes to the source module, not the target module, as compared to its base.

Another way to think about this is to remember that we are integrating the changes from the source module to the target module, so the changes to the target module are not under scrutiny.
Select object ORG_19 now. Looking at the Changes in Source Module box you see two changes. If you expand its list, you see the two changes. Selecting a change will cause the Changes in Source Module box to only show the one change selected. This is a handy way to remove clutter when looking at particular changes.
Now select the list entry called "module ORG_0". This entry represents changes made to module attributes. We see that the source module’s Test Status was changed since the base, from Not Tested to Under Test.
Let’s look at a conflicted change now. A conflicted change happens when both the source and target objects have changed in some way (not necessarily the same attribute or link). Double-click on the conflicted change list entry for object ORG_13.
If we look at the base module baseline, we see the heading for ORG_13 as it was to begin with.
If we look at the source module, we see that the heading for ORG_13 was changed.
And if we look at the target module, we see that the heading for ORG_13 was changed, but in a different way than the source module. This is explained in the columns created by the integration script, as well as in the Integration of Module GUI’s Conflict Information text box on the right-hand side.

There is one more situation to understand before moving on to merging changes. In the target module, notice that ORG_11 has source and target changes. However, if you look at the Integration of Module GUI, there is no line for this object. That is because the changes are the same, so no merging is needed.
Now that we understand how to interpret the changes described by the integration script, let’s merge some changes from the source module to our target module. Select the change for module ORG_0. We see that the source module changed the module attribute Test Status, from the base Not Tested, to Under Test. If you view the target module’s value, it is Not Tested, and thus has not changed since the base.

Press the Merge Selected Changes button.
You see that the module ORG_0 line has disappeared. If you view the target module’s Test Status value, you see that it is now Under Test, i.e. it has been changed to match the source module change.

With the next line highlighted, object ORG_12, press the Merge Selected Changes button.
Again, you see that the object ORG_12 has disappeared. When you view the target module, you see that ORG_12’s Object Text has been changed to what the source module’s Object Text was.

In the Integration of Module GUI, with the next line highlighted (object ORG_17), press the Merge Selected Changes button.
As before, the object ORG_17 has disappeared. When you view the target module, you see that ORG_17 no longer has an out-link.

In the Integration of Module GUI, with the next line highlighted (object ORG_18), press the Merge Selected Changes button.
When you press the Merge Selected Changes button in the Integration of Module GUI for object ORG_18, and look at the object in our target, you will see an out-link has been added.
In the Integration of Module GUI, select the line for object ORG_21, and press the Merge Selected Changes button. If you look at the target module now, you will not see the object because it was deleted. Choose the View > Show > Deletions menu option in the target module, and you will see the deleted object ORG_21 . You also see deleted objects ORG_22.
In the Integration of Module GUI, select the line for object ORG_22, and press the Merge Selected Changes button. If you look at the target module now, you will see the object is now undeleted.
In the Integration of Module GUI, select the line for object ORG_23, and press the Merge Selected Changes button.
In the Integration of Module GUI, select the line for object ORG_25, and press the Merge Selected Changes button. If you look at the target module now, you will not see the object, even if you show deletes, because the object has been purged.
Now let’s merge a conflicted change. In the Integration of Module GUI, select the line for object ORG_13. This object is conflicted because both the source and target objects were changed since the base, and those changes are not the same (like they were for ORG_16).

Press the Merge Selected Changes button.
Because you are attempting to merge conflicted changes, the script warns you of possible unintended consequences. Press the Confirm button.
If we look back at the target module, we see that the heading has been changed to what it is in the source module. So while this instance of merging conflicted changes worked as we would expect, the script cannot always merge conflicted changes so well. You should always double check the merged changes for conflicts.
What if you don’t wish to merge a change into your target module? Simply select the line, in this example select object ORG_54, and press the Mark Object as Integrated.
You see that the line disappears from the GUI list of changes. Now turn your attention to our target module, right-click on object ORG_54, and select the menu option Properties...
If you look at the Attributes tab, you see that the Test Status attribute remains as Not Tested, rather than taking on the source module value of Tested. You can also see the Last Integrated On value is set. This is how the script knows that the object no longer needs to be merged.

Press the OK button to dismiss the object properties dialog box.
If we needed to stop integrating the source changes into the target module, and wanted to continue at a later time, we could press the Save and Continue Later button.


Before finalyse the integration, we will Merge at once all the Non Conflicted Changes.
Instead of selecting each Non Conflicted Changes and use the 'Merge Selected Changes' button, we can use the 'Merge All Non Conflicted' button to automatically integrate all.

Select a Non-Conflicted change to start with, the press the 'Merge All Non Conflicted' button.
A confirmation dialog box will appear, asking you if you really want to automatically integrate all Non Conflicted Changes.

We will accept it. Click on 'Yes, integrate all non-conflicts'
We can see all the 'Non Conflicted Changes' are merged !

So now, we have merged all the changes wanted and we will finalyze the integration.

Press the Finalize Integration button.
The script will display a dialog box allowing you to customize the integration baseline that must be made after every integration. You can change the baseline version if you like, incrementing the minor or major number (or not at all, as is the default). You can also change the suffix and add some descriptive text.

When you are ready, press the OK button.
Since we integrated changes from the current version of the source module, the source module must also have an integration baseline created.

Press the Confirm button.
After the baselines are created, a dialog box will announce their completion. Press the OK button. You have completed an integration!