The OBIEE Multi User Development Environment makes use of the three way merge process. The process itself is described below. This is useful when planning mechanisms in a multiuser development environment.
When we Checkout a Project we create two RPD files on our local development machine; one is a snapshot of the Shared MUD RPD, generally referred to as the Original; the other is a subset of the MUD RPD containing only our selected project(s), generally referred to as the Modified version. The Original version will be used during Checkin to help determine why any conflicts have occured between the shared MUD RPD and the Modified version.
Changes are configured in the Modified version of the RPD. When we want to check these changes into the Current (shared) RPD then we start by Merging Local Changes. When we do so, as shown in the diagram below, a lock is placed on the MUD RPD and a current snapshot is copied locally; the lock ensures the validity of the snapshot (Current.rpd).
The Original, Modified and Current RPDs will be analyzed and conflicts displayed to the user if choices are required. Once conflicts are resolved the 3 way merge will be actioned, producing a single Merged RPD. The lock remains on the MUD.rpd; again, ensuring the validity of your Merged.rpd.
You can see from the schematics that throughout this process the MUD RPD has been locked to prevent other changes being made. The final step to the process is for us to Publish our Merged RPD, releasing the lock and overwritting the MUD.rpd.
That is the process completed; the MUD is unlocked and other users are now free to Checkin their changes. It should be noted that at any point in the process, until we Publish, we could back out our changes by Discarding Local Changes; this would delete our local files and release the lock on the MUD enabling other developers to checkin their changes.
But How Does this Help Me?
We can action a 3 way merge manually by selecting Merge from the File Menu and certainly, as a developer, there will be a point where you will need to merge one code stream into another, or more correctly a branch of code into the trunk. There are many ways to achieve this, all with their pros and cons; I have found the most reliable method to be the Parentless 3 Way Merge.
When we Checkout a Project we create two RPD files on our local development machine; one is a snapshot of the Shared MUD RPD, generally referred to as the Original; the other is a subset of the MUD RPD containing only our selected project(s), generally referred to as the Modified version. The Original version will be used during Checkin to help determine why any conflicts have occured between the shared MUD RPD and the Modified version.
The Checkout Process
Merging Local Changes
The 3 Way Merge
Publishing the Merged RPD
Discarding Local Changes
We can action a 3 way merge manually by selecting Merge from the File Menu and certainly, as a developer, there will be a point where you will need to merge one code stream into another, or more correctly a branch of code into the trunk. There are many ways to achieve this, all with their pros and cons; I have found the most reliable method to be the Parentless 3 Way Merge.
No comments:
Post a Comment