Merging Local Changes
After all changes are finished, the developers must check the project into the master repository in the multiuser development directory. Only one developer at a time can merge metadata from a local repository into the master.
The following actions occur when the checkin (merge) process begins:
1. The Administration Tool determines whether the shared master repository is currently locked. If not, it locks the shared master repository, preventing other developers from performing a merge until the current merge is complete.
2. If there are any conflicts, the Merge Repository Wizard opens and displays the Define Merge Strategy page. You then make merge decisions about whether to include or exclude objects by choosing Current or Modified from the Decision drop-down list.
3. A local version of the master repository opens.
4. The Administration Tool automatically creates a comma-separated value (.csv) file in the local repository directory on the developers machine. This file lists changes made to the shared master repository during the merge.
5. A new file is created in the shared master repository directory with a modified subset.
To merge your changes to the master repository, perform the following steps:
1 . Select Adam’s Administration Tool. Click File > Multiuser > Merge Local Changes. This locks the shared repository until checkin is complete.
The Merge Repository Wizard briefly flashes.
If any conflicts exist, the Merge Repository Wizard – Define Merge Strategy dialog box would appear. You would then make merge decisions about whether to include or exclude objects by choosing Current or Modified from the Decision drop-down list.
2 . The SharedMaster repository opens. Expand A – Sample Sales to verify that the deleted objects (Customers
and Cust Regions) do not appear.
At this point, you can undo the local merge, discard the local changes, or publish the repository. These options are available from the File > Multiuser submenu.
If other local repositories need to be merged (for example, hmayes.rpd), you must merge these before publishing. When working in a MUDE, the master repository is not locked when you merge local changes. Instead, the master repository is locked during the “Publish to Network” step. This reduces the total time that the master repository is locked to avoid lock contention issues.
An Oracle best practice is to publish immediately following the merge.
3 . As noted in the introduction to this topic, a merge log file (*.csv ) is created that contains the merge changes.
Navigate to <ORACLE_INSTANCE>\bifoundation\OracleBIServerComponent\coreappplication_obips1\repository
and open SharedMaster.merge_log.csv.
4 . Review the changes in the merge log file.
5 . Close the log.
Publishing Local Changes
After all local repositories are merged, you publish the local changes to create a new master repository. The publish step checks to ensure that no other developer published changes to the master between the time that you merged local changes and the time that you published to the network. If the program logic discovers that another repository developer has published to the network in this time period, the system will automatically redo the merge with the master, rolling back the repository version that you used for the Merge Local Changes step, and then it will merge your changes with the new master.
To publish the local changes, perform the following steps:
1 . Adam had previously sent out an email reminding his peers that he was ready to merge and publish the new repository. Helen did not see the email. Adam continues with his task. In Adam’s Administration Tool, click File –> Multiuser –> Publish to Network.
Do not check for consistency.
2 . The Lock Information dialog box appears. The master repository is locked to prevent concurrent update.
Enter Adam Bell in the Full Name text box and enter a comment for documentation into the Comment text box.
3 . Click OK. If you receive a message prompting to use this full name, click Yes.
The local copy of the master repository merges with the master repository in the shared folder.
That is, Adam’s changes are merged into SharedMaster, and then, originalabell.rpd,
abell.rpd.Log, and abell.rpd files are deleted. The SharedMaster repository within Adam’s
Administration Tool closes.
Resolving Issues for a Repository Update
1 . Helen wants to assist with the devlopement effort. She decides that she will perform the publication of the repository to the network (not knowing that Adam has already merged and published the repository).
Before Helen can publish, she needs to perform a merge (although she has not made any changes to the repository ). In Helen’s Administration Tool, click File > Multiuser > Merge Local Changes. The Merge Repository Wizard – Define Merge Strategy dialog box appears.
2 . Select the first row of the Conflicts table. The Differences pane refreshes with conflict details.
3 . Click the ellipsis button ( ) to the right of the Differences pane to review the details of the objects that were modified.
4 . Click Cancel.
5 . Notice that the repository panes area displays the original (originalhmayes) repository, along with her modified repository, and the current (SharedMaster) that was updated by Adam.
At this point, Helen must make a decision about how to proceed with the merge. Realizing that there is a conflict between her version and the master, Helen contacts Adam and resolves the issue.
Interested in mastering OBIEE Training? Enroll now for FREE demo on OBIEE Training.
6 . In the Conflicts table at the top of the wizard, select the Decision drop-down list for the Customers table, and then select Current. This selection chooses the current repository (the repository that does not contain Customers and Cust Regions) over Helen’s version.
7 . In the Conflicts table at the top of the wizard, select the Decision drop-down list for the Cust Regions table, and then select Current.
8 . Click Finish.
9 . Click File > Save and do not check for consistency.
10 . Click File > Close, leaving the Administration Tool open.
Reviewing the History and Verifying the New Repository
You can review all modification activity by reviewing the history associated with the MUDE.
To review the history, perform the following steps:
1 . Click File > Multiuser > History and when prompted, enter the password.
The “SharedMaster.rpd Multi User History” dialog box appears.
2 . Right-click the Version 1 row and select View > Details.
3 . The “Version 1 details” dialog box appears. This shows all multiuser changes.
Click X to close both the “Version 1 details” and ” SharedMaster.rpd Multi User History” dialog boxes.
4 . Next, open the new repository. Click the Open Offline icon ( ), navigate to <drive>:\RPD, and select SharedMaster.rpd.
5 . Click Yes to acknowledge that you can only open it as a read-only file.
6 . Enter the password. The new repository appears.
7 . Expand A – Sample Sales in the Presentation layer and verify that the new repository changes have been merged successfully and that the Customers and Cust Regions objects are not part of the new repository.
Click File > Exit to close the Administration Tool.
8 . Navigate to <drive>:\RPD and notice that a new subset file appears. If you need to roll back the changes, you can use this subset to accomplish that task.
For indepth understanding of OBIEE click on