ClearCase Synchronizer job fails creating elements
We have a problem with the synchronizer when creating new files in RTC and wanting to sync them to ClearCase.
It happens always this way. Import from ClearCase works fine, changes to existing files are ok too. How could we stop this behaviour? The Sync Host is running Windows 7. RTC 4.0.1 is used, and Rational ClearCase 7.1.1.4. I create a new file in the merge workspace and deliver this to the synchronized stream. The file name is unique, by using a date stamp as part of the file name: di_dummy1/test2/rtc-new-20130725-1850.txt (added) The following sync fails with these entries in build.log: Processed activity "Created baseline in component: di_dummy1" in 4932 millisecond(s) However, when I look into the view, the new element di_dummy1\test2\rtc-new-20130725-1850.txt has been created! I could not believe the "Pathname not found error" to come out ouf cleartool mkelem, but all trigger scripts return positive status (0). The next sync ends throws a different Exception: VOB database schema version: 54 and as a side-effect, the file in question gets renamed in ClearCase to "rtc-new-20130725-1850.txt_1". If I now rename the file back to the original name, it looks as a change from ClearCase. The next sync (3) will turn yellow and flag it as a Merge Conflict. This resolves very easily in the merge workspace. I can now run another sync (4) to get a green sync status again. Finally, I ran the cleartool mkelem command manually. You can see the error message in the output, but also that the exit code of cleartool is successful (0): C:\Windows\system32>cleartool mkelem -comment "Manual New File" -ci -master R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txtSo, could it be that the synchronizer scans the printed result of cleartool mkelem for additional errors, and gets thrown off by these messages? BR, Peter |
Accepted answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 27 '13, 11:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jul 27 '13, 2:43 p.m.
The synchronizer uses both the cleartool exit code and error strings written to stderr to detect errors (there are cases where the exit code is 0 but there are important errors reported in stderr).
It looks like you have some trigger that is causing error messages to be written to stderr, but then returning with exit code 0. You will need to fix those trigger scripts so they either do not write errors to stderr, or are not invoked during synchronization (the synchronizer sets a special environment variable so you can easily detect in the trigger script that it is running in a synchronizer context). WRT how you make your changes, it doesn't matter what client you use, or what changes you make to either the ClearCase or RTC side ... they will be correctly synchronized once you fix-up your trigger scripts to not write errors to stderr when you want the command to succeed. Peter Vohmann selected this answer as the correct answer
Comments We found and verified that one of the triggers is attached to both rmname, lnname operations, that runs cleartool lsco on the path that (in this case) is not yet under source control.
|
One other answer
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Oh, one more thing:
As you can see above, I had created a new file manually on the synchronized ClearCase branch. When I run the synchronizer, the new file from ClearCase is not found and not imported. Instead, the synchronizer has created a new directory version that removes the file element!!
There seems to be a difference, wether I create the files using ClearCase Explorer, or if I use cleartool mkelem.
Of course, one difference is that I have to manually check out the directory version, and manually check it in again. Could it confuse the synchronizer, if he runs between these check-ins - that logically should belong together?
G