Before branching, you need a project to branch into. For the purpose of this lesson, create a new project in the Branch Lessons folder as shown: right-click in an empty space of the list view on the right side of the database explorer, choose New > Project... Enter a name for the new project, e.g. "2-1 Branch [username]", and press OK. |
![]() |
The new project will appear in the Branch Lessons folder. |
![]() |
Now start the "Branch Modules" script by choosing the Configuration Mgt > Branch Modules menu option. |
![]() |
Quick description of the Branch GUI parts:
|
![]() |
First, choose the module baseline to branch by pressing the Select Modules button. |
![]() |
Using the Tag List Editor that appears, navigate to Module X in the project for this lesson. Double-click the "1.1" baseline of Module X. |
![]() |
After you have chosen the "1.1" baseline of Module X, press the Use selected Modules button. |
![]() |
You see that the module and baseline now appear in the module list. Next, select the target project to branch the module into by pressing the Browse button. |
![]() |
Choose the new project in the Branch Lessons folder that you created and press the OK button. |
![]() |
You see that the project appears in the text field. Press the Start Branch Copy button to start the branch process. |
![]() |
After you press the Start Branch Copy button the branch process will begin. A small dialog box will appear announcing the various stages of the branching process and showing the total advancement with a progress bar. When the branching is complete, an information box will appear. Press the OK button. |
![]() |
The focus returns to the Branch Copy GUI. We are finished with it, so press the Close button. |
![]() |
You can see that Module X has been copied to the project you created. |
![]() |
Let us analyze the branched Module X and see how it is the same and different than the original Module X. |
![]() |
In the branched Module X, choose the Edit menu, option Types... |
![]() |
A dialog box will appear with a Types tab.
Here we see that the Test Status Type, which is not a DOORS system type but was created by a user,
has been created in the branched module. When branching a module, Branch Manager copies all the non-system types. |
![]() |
Click on the Attributes tab next.
Notice that the attribute Test Status, which is not a DOORS system type but was created by a user,
has been created in the branched module. When branching a module, Branch Manager copies all the non-system attributes. Click the close button. |
![]() |
Next let us look at the module attribute values. In the branched Module X, choose the File menu, option Module Properties... |
![]() |
A dialog box will appear with a General tab.
Here we see that the Test Status module attribute value has been copied to the branched module. When branching a module, Branch Manager copies all the non-system module attribute values. Also, notice there are extra module attributes, i.e. module attributes that do not exist in the original Module X. These module attributes hold data used for matching, comparing, and merging modules. These attributes should never be manually edited! When branching a module, Branch Manager creates (or updates) special module attributes to keep track of branching and merging operations. Click the close button. |
![]() |
Now click on the View drop down box.
We see that the Test View from the original module has been copied to the target module. When branching a module, Branch Manager copies all the non-system attribute definitions. Choose the Test View in the View drop down box. |
![]() |
There are several things to notice here.
First, it should be obvious that object attribute values have been copied.
Scroll down and you will see this applies to tables, pictures, and OLE. When branching a module, Branch Manager copies all the non-system object attribute values, including tables, rich text, pictures, and OLE. Second, the structure, or hierarchy, of the objects has been copied. That is, how the objects relate to each other in parent, child, and sibling relationships has been copied. When branching a module, Branch Manager copies the object hierarchy structure. Third, the deletion status of objects has been copied (MOD_5, MOD_6, and MOD_7). So if an object was deleted in the original module, it will be deleted in the branched module. When branching a module, Branch Manager copies the object’s deletion status. |
![]() |
It is important to notice that the exact object absolute numbers have been preserved during the copy, even for those objects that have been purged. Press Control-G to start the "Go To" dialog, and enter "8" in the text field. Then press the "Go To" button. |
![]() |
You see that the object with absolute number "8" is missing, i.e. it was purged, just like in the original module. When branching a module, Branch Manager copies the object’s purge status. Press the OK button to continue. |
![]() |
We saw that the branch operation created special module attributes, now let’s look at the object versions. Right-click on an object and select the option Properties... |
![]() |
Select the Attributes tab and you can see the special object attributes that hold data used
for matching, comparing, and merging objects.
These attributes should never be manually edited! When branching a module, Branch Manager creates (or updates) special object attributes to keep track of branching and merging operations. |
![]() |