In the Lock Information dialog, in the Comment field, type a description of the After you confirm all the changes, click Save.

3-16 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition This is necessary because the master repository in the multiuser development directory might have changed after the developer checked out the projects. To check in projects to the master repository: 1. In the Administration Tool, select File Multiuser Merge Local Changes, then click Yes if prompted to save changes.

2. In the Lock Information dialog, in the Comment field, type a description of the

changes that you made, then click OK. Figure 3–3 shows the Lock Information dialog. Figure 3–3 Lock Information Dialog 3. If there are any conflicts, the Merge Repository Wizard opens and displays the Define Merge Strategy screen. Make merge decisions about whether to include or exclude objects by choosing Current or Modified from the Decision list. When you select an object in the decision table, the read-only text box below the decision table describes what changes were made to that object in the current repository. You can also click View Change Statistics to see a summary of changes. Click Finish when you are finished making merge decisions. See Performing Full Repository Merges for additional information about the Define Merge Strategy screen. A lack of conflicts does not mean that there are no differences between the repositories. Instead, it means that there are no decisions that have to be explicitly made by the developer to check in changes. See How are Multiuser Merges Different from Standard Repository Merges? for information about conflicts that are resolved automatically in a MUD merge. In both cases, a CSV file is created in the local directory that contains details of the merged changes.

4. After you confirm all the changes, click Save.

This saves the merged repository locally, and then uploads this repository to the multiuser development directory with an incremented numeric file extension for example, Master_Sales.000, Master_Sales.001, and so on. At this point, the changes made by the developer are still not saved to the master repository in the multiuser development directory. 5. To commit these changes to the master repository in the multiuser development directory, select File Multiuser Publish to Network, then click OK. Setting Up and Using the Multiuser Development Environment 3-17 The master repository in the multiuser development directory is overwritten with the copy of the repository containing the developers changes. Tracking Changes to the Master Repository You can find a summary of the development activities on the master repository in master_repository.log. This log contains a record of the following activities: ■ Projects that have been checked in and checked out and when these actions occurred ■ The Windows login name and computer name initiating the transaction ■ When locks are created and removed Branching in Multiuser Development Branching is a further refinement of the merging development process. Branching can provide higher efficiencies over large development teams that have overlapping releases, but it requires significant administrative overhead. This section contains the following topics: ■ About Branching ■ Using the Multi-Team, Multi-Release Model in Oracle Business Intelligence ■ Synchronizing RPD Branches About Branching In branching, developers work on private branches to isolate their code from other developers and merge changes back to the main branch. Different strategies can be followed, depending on the size of the development team. In the Simple Development Model, all development occurs on a single main branch. This strategy has the following characteristics: ■ Only for emergency fixes ■ Checkouts may not be most current code ■ Carries a stability risk for the mainline branch Figure 3–4 shows the Simple Development Model. Figure 3–4 Simple Development Model In the Small Team Development Model, development occurs on a single Dev branch, with a separate Main branch strictly for releases. This strategy has the following characteristics: 3-18 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition ■ The Mainline is the official release branch ■ Development occurs on a separate branch ■ Stable code is merged back to Main at key milestones ■ Branches are synchronized periodically Figure 3–5 shows the Small Team Development Model. Figure 3–5 Small Team Development Model In the Multi-Team, Multi-Release Model, development occurs on multiple Dev branches, again with a separate Main branch strictly for releases. This strategy has the following characteristics: ■ Supports more efficiency over disparate teams ■ Development occurs on separate branches ■ Stable code is merged back to Main at key milestones ■ Branches are synchronized periodically Figure 3–6 shows the Multi-Team, Multi-Release Model. Figure 3–6 Multi-Team, Multi-Release Model Setting Up and Using the Multiuser Development Environment 3-19 Using the Multi-Team, Multi-Release Model in Oracle Business Intelligence Using complex branching strategies in Oracle Business Intelligence requires attentive organization of repository files, as well as altering the Multiuser setting in the Administration Tool. The following procedure provides an overview of the required steps. To use the multi-team, multi-release model branching strategy: 1. Create a Main repository Master Repository and store it in the Master multiuser development directory. ■ Projects must be explicitly defined. ■ Branch developers should not have access to the Master directory.

2. Create a subset of branch repositories by extracting from Main and storing them as