How Does M+R Work?
Scenario: Vendor Code Reconciliation
Suppose you are a systems manager, and your site runs Release N of a vendor product.
You have applied fixes and modified the vendor product to customize it for your users. When the vendor announces the next release, (N+1), your users want it installed immediately. You are now faced with a version migration filled with these complications:
-
If you install release N+1 as is, your own custom modifications are regressed.
-
Some of the vendor’s fixes duplicate your own changes, so not everything you have done must be reapplied.
-
It took you many months to evolve modifications for release N, and neither you nor your users want to wait that long for the next release customization.
-
The upgrade job looks long, painful, and error-prone—particularly if the vendor has renumbered the source code lines. You need a fast, intelligent method to blend the vendor’s upgrades and your custom modifications into a working product.
Solution: M+R
M+R can handle this problem. First, you have to identify the source files (the base version and derivatives) to M+R.
-
The base is the Release N of the vendor product.
-
One derivative is the current production library that contains your customizations.
-
The other derivative is the Release (N+1).
Then, you run M+R, which performs the following steps:
-
Compiles member lists of the base/derivative libraries and matches same-named members in version sets.
-
Loads the chosen base members and the derivatives’ members into storage.
-
Compares the base version with each of the derivatives, records the differences, then compares and combines them.
-
Stores the base version and the differences in the M+R work-in-suspense file.
-
Identifies conflicts and single changes.
-
Calculates the degree of complexity of the reconciliation effort, and stores the relevant statistics.
-
Displays a full view of the merged versions, formatted graphically and in color, for reconciliation.
-
The following figure illustrates schematically how M+R reconciles different releases of software.
The following table shows the steps that you must take in order to merge and reconcile.
Steps | M+R Function | Meaning |
---|---|---|
1 | M+R compares Version A to Version B | This comparison identifies the changes and modifications added to the vendor code release by your company. |
2 | M+R compares Version A to Version C | This comparison identifies vendor’s changes between Release N and Release N+1. |
3 | M+R merges and combines the differences with Version A | By presenting the combined versions for browsing and editing, you can see the differences between all the versions. |
4 | Reconcile the changes | Now, you reconcile the changes to create a conflict-free consolidated version that includes Vendor Software Release (N+1) and your company‘s modifications. |
5 | M+R extracts the reconciled code and creates Version D | Version D is the new production software containing the new (N+1) vendor release plus all the needed customization minus those user modifications (fixes) that have already been addressed in the (N+1) release. |