EWM:Version Conflicts
Version Conflicts
What are Version Conflicts?
If different versions of the same object are maintained at the same time, TD/OMS requests a confirmation when the second (or higher) version of the object is moved to production. This is tracked by writing a record in the Version Conflicts Table (OMOVC) which will also keep the confirmation history.
A Version Conflict record is created when an object is checked out from production (PRE V160KEM03) or promoted and checked-out (POST V160KEM03).
Maintenance of different versions of the same object at the same time can occur more or less frequently depending on the (defined) cycle. Cycles with an emergency environment and cycles with Application interface definitions are good candidates for version conflicts.
An example: An application has 4 environments:
*EMER | Emergency |
*DEV | Development |
*TEST | Test |
*PROD | Production |
Now, the following happens:
- Program X is copied from *PROD to *DEV.
- Program X is moved to *TEST.
- Program X in *PROD contains a bug that must be fixed a.s.a.p. It is copied from *PROD to *EMER.
- Program X is moved from *EMER to *PROD. The version in production is replaced. Program X in *TEST is now based on a version that no longer exists in *PROD.
If confirmation of version conflicts is required, program X in *TEST cannot be moved to *PROD without confirmation.
Confirm Version Conflicts
The version conflict confirmation process can be activated by selecting Confirm Version Conflicts in the context menu for a Solution, Task or Application or by opening the TD/OMS Version Conflicts view, selecting a Solution, Task or Application and selecting Confirm Version Conflict in the context menu after selecting the conflicts to confirm (see this link for information about the TD/OMS Version Conflicts view).
A panel shows all selected objects:
Deselect the conflicts that should not be confirmed and press the OK-button to confirm the selected conflicts.
By default the potential version conflicts are hidden, only the active version conflicts will be visible. A potential version conflict is a conflict between to tasks, but neither of the tasks have been moved to the final stage.
When is Version Conflict confirmation active?
It is possible that a warning appears when confirming:
In that case, start TD/OMS on your IBM i and issue the command STRSD (You must have TD/OMS manager or security officer authorisation to do this) . This will show the setting for Confirm Version Conflict. If it is set to zero, there is no need to confirm the version conflicts. However, the Version Conflicts View can always be opened.
Compare and Merge Sources
You want to be able to compare your current version of your source with any archived version. You also want to compare and merge the changes that your co-worker added in an emergency session. For this the Compare functionality has been added.
You can select an object or a solution and use the "Compare With.." context menu option. Select "Revision.."
A list will be populated with all known versions of this source and it will be displayed sorted on version number with the latest version on top of the list.
The three lines above mean the following.
- The top two lines show the production source and a safe copy of that source. Task F2839 was used to change the file.
- The third line shows our selected source in green as it currently is in development in Task F3223
Performing a right click on any of the revision lines will show the menu option 'Show Task info' and if the selected object is a stream file then you will also get the menu option 'Checkout revision to project'. With the 'Show Task info' the 'Related work info' view will be shown with relevant task information made available.
With the 'Checkout revision to project' it is possible to directly checkout the selected revision file to an Eclipse project. The target file name will be the original stream file name with a the revision number added, for example DMP000001 with revision 1.1 will become for example StrFileIfs-1_1.txt (where StrFileIfs.txt was the originally archived stream file and is the name of the most current revision). The target Eclipse project will be presented in a list, those projects that are team connected to TD/OMS will have the application and host set.
Selecting a source for Compare
Suppose you want to merge the changes from the task F2839. You can compare with the version of the source before the change (DMP0003241) or the version after the change (the top line).
Just doubleclick the desired entry and the compare view will be populated
Please note that the source line change date is moved to the beginning of the source. This enables preservation of the source line change date. The sequence of the source is not preserved and the source will be re-sequenced once opened again with the LPEX or SEU editor.
Making changes
When you select a development or emergency solution you are able to edit this file by manually coding changes or by using the compare editor. When using the compare editor click the right-to-left option to get a change block from the other version.
After the source was changed, pressing the save icon (or CTRL+S) will save the merged version into the development source.
NOTES
You have to give enough access to the '/QOpenSys/TD/tmp/CMWDIR' directory or any other directory that you designate as work directory with the OMQWORKDIRCANDM registry setting.
*PUBLIC needs to have *RWX on '/QOpenSys/TD', '/QOpenSys/TD/tmp' and '/QOpenSys/TD/tmp/CMWDIR'
Control characters in the source will be removed when you save.
Three way compare I
If you select two elements in the list (hold the CTRL key while selecting) and double-click you get prompted with a question. Choose "No" the start a three way compare.
The object with the lowest version number will be the common ancestor except when this is the object that was selected from the components view. You can show the ancestor by clicking the reveal ancestor button.
Three way compare II
You can also invoke the three way compare by selecting three objects in the components view. This is more useful than it seems because especially when two objects are simultaneously being developed it makes sense to select the two objects and the object in production. Then select compare with each other from the context menu.
A dialog will popup which enables you to select the common ancestor. This is mostly the production object which is most of the times the object with the lowest version number.
You can show the ancestor by clicking the reveal ancestor button.