A three-way merge is widely seen as the most robust method for revision control in the IT industry, and it is recommended by Oracle. It is especially important to have a robust process when you are merging repositories with the same base and, possibly, conflicting objects. In our example, we will have three RPDs:

So let's begin. Firstly, open the current repository (in offline mode) and navigate to File | Merge...:

You can see the Merge Repository Wizard - Select Input Files screen in the following screenshot:

Then select the Original Master Repository  and Modified Repository, and input their passwords too. Also select the Full Repository Merge radio button at the top of the Merge Repository Wizard - Select Input Files  screen, as we are dealing with whole repositories.

Note that we have checked the Equalize During Merge box. This solves a potential issue where the same object in both changed RPDs have different object IDs. This can happen if we needed to recreate the object from scratch in one of the RPDs.

Once this has been done, click on Next. At this point, you will get the option to check the global consistency of all the RPDs that we have referred to. In preparation for this process, we should have already verified this and been happy with the results, so click on No.

The merge tool will now check for conflicts between the RPDs. If there are any conflicts, those will be displayed in the Merge Repository Wizard - Define Merge Strategy screen. Here we will be able to choose how to rectify the conflict:

In the preceding screenshot, you can see that we only have one conflict and they all stem from differing names for the EnglishMonth column in the three RPDs: EnglishMonthName, English Month, and EnglishMonth. Via a radio button, we can choose whether to go with the Modified (Current PROD) or the Current (DEV) version. Let's go with the DEV version, as our users wanted that updated.

Once we have resolved all conflicts to our satisfaction, check the Check consistency of the merged RPD box. This is good practice, as it ensures that the consistency of the newly merged RPD is ascertained straight away.

Note that if we want a file record of all of the conflict resolution decisions that we have made, we can generate that using the floppy disk icon on the top right of the screen:

Once we are happy, we can click on Next and the merge process takes place. This may take some time depending on how big your RPDs are, and how many merge conflicts need to be resolved.

Once the process has finished, we are left with the Current RPD file, but with the newly merged changes within it.

This is commonly carried out when you have two separate RPDs that need to be merged, but they have no common parent. This happens when, for example, you are combining two entirely separate streams of work. An example of this would be the AdventureWorks core model and a separate usage tracking model. If the two RPDs contain completely different subject areas, business models, and data sources, you can easily cut and paste these objects entirely from one RPD to another. However, this is sometimes far from ideal and requires an experienced and knowledgeable developer who has implicit knowledge of both RPD developments.

Best practice in this case is to carry out a two-way merge using the previously discussed merge tool. This time when you are prompted for an original RPD, as we do not have an original trunk parent, you can provide a dummy RPD. This is known as a parentless three-way merge.

Now consider a scenario where you need to merge multiple RPDs, and the possibility that your project and RPD have become so large that you will need multiple developers. In small proven teams, access to the RPD for development can easily be maintained through open communication, such as verbal means or even e-mail/messaging in conjunction with a change log where developers record their amendments. However, in larger teams where there is the possibility of development conflicts over shared objects and the need for more robust version control, we will need to look at other options.

One option is to have the RPD accessed via a centrally running OBIEE environment. This means that all developers will access the RPD in an online mode via the Administration tool. When working on objects, developers will have to check them in and out on the server itself.

Therefore, from the Administration tool, we can open the online repository by navigating to File | Open Online or by choosing the blue folder icon in the toolbar:

We are then prompted for the online RPD details:

Once we are within the online RPD, we can amend the objects that we want to change. So let's change the name of the Month logical column. Double-click on the EnglishMonthName logical column. At this point, you will see the Check Out Objects screen:

Note that all associated objects up to the business model level have also been checked out, even when such a simple amendment is made. Once we click on Check Out, we are then returned to the RPD. However, note that the icons have changed for the objects that we have checked out. This shows that they are locked for the amendment:

Once we have made our change, we can check in the objects by choosing the check-in icon in the toolbar, as shown in the following screenshot. As a general tip, note how you can see that we are in online mode due to the Online title heading of the Administration tool:

Once you are happy with the amendments and have checked in your objects, you will be asked to confirm whether you want to run another global consistency check.

We are also reminded that if we are in a clusteredenvironment, we will need to restart these nodes. This is done through the Enterprise Manager.

There are multiple drawbacks to this method: