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:
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:
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):
and gets thrown off by these messages?
BR,
Peter
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)
Jazz:
Number of files created = 0
Number of files updated = 0
Number of folders created = 0
Number of folders updated = 0
Number of symbolic links created = 0
ClearCase:
Number of files created = 0
Number of files updated = 0
Number of folders created = 0
Number of folders updated = 1
Number of symbolic links created = 0
Problem running 'synchronizeStream':
Synchronization blocked by error:
javax.wvcm.WvcmException: CRRTC4061E: The synchronization process cannot be completed. The "cleartool" command completed with a non-zero status or error message:
cleartool mkelem -comment Change from Synchronized Stream: test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02 -ci -master R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1850.txt
Checked in "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1850.txt" version "\main\test_vop2hi_rtcsync_tas_try2\1".
cleartool: Error: Pathname not found: "R:\DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02\di_dummy1\test2\rtc-new-20130725-1850.txt".
current working directory: R:\DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02
command result status: 0
command duration: 1670 ms
process environment:
Build failed. Exit value was 3.
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
Starting operation: synchronize
WARNING: Current runtime locale "en_DE" does not match stream's declared locale "de_DE".
Processed activity "Created baseline in component: di_dummy1" in 8231 millisecond(s)
Computing changes in component: di_dummy1
Computing changes in synchronized stream
Computing synchronized roots in other repository
Transferring 2 changes
Found no sub VOB components in VOB: "\di_dummy1"
Processed activity "Created 1 link" in 5882 millisecond(s)
Processed activity "Created baseline in component: di_dummy1" in 14 second(s)
Jazz:
Number of files created = 0
Number of files updated = 0
Number of folders created = 0
Number of folders updated = 0
Number of symbolic links created = 0
ClearCase:
Number of files created = 0
Number of files updated = 0
Number of folders created = 0
Number of folders updated = 0
Number of symbolic links created = 0
Problem running 'synchronizeStream':
Synchronization blocked by error:
javax.wvcm.WvcmException: Resource does not exist: CONTROLLABLE_RESOURCE|R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1850.txt
Build failed. Exit value was 3.
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,
cleartool: Error: Pathname not found: "R:\DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02\di_dummy1\test2\rtc-new-20130725-1859.txt".
Created element "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txt" (type "text_file").
Created branch "test_vop2hi_rtcsync_tas_try2" from "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txt" version "\main\0".
Note: Branch "test_vop2hi_rtcsync_tas_try2" explicitly mastered by replica "original".
Branch type "test_vop2hi_rtcsync_tas_try2" mastered by replica "original".
Checked in "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txt" version "\main\test_vop2hi_rtcsync_tas_try2\1".
C:\Windows\system32>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.txt
cleartool: Error: Pathname not found: "R:\DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02\di_dummy1\test2\rtc-new-20130725-1859.txt".
Created element "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txt" (type "text_file").
Created branch "test_vop2hi_rtcsync_tas_try2" from "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txt" version "\main\0".
Note: Branch "test_vop2hi_rtcsync_tas_try2" explicitly mastered by replica "original".
Branch type "test_vop2hi_rtcsync_tas_try2" mastered by replica "original".
Checked in "R:/DO_NOT_USE_test_vop2hi_rtcsync_tas_try2_TEST_VOP2HI_RTCSYNC_13.0V02/di_dummy1/test2/rtc-new-20130725-1859.txt" version "\main\test_vop2hi_rtcsync_tas_try2\1".
C:\Windows\system32>echo %ERRORLEVEL%
0
and gets thrown off by these messages?
BR,
Peter
Accepted answer
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.
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.
One other answer
Hi Peter,
Take a look at the section titled:
"If you notice the following error in the sync log, then set MVFS to preserve case by navigating to and settingCase Insensitive MVFS and Case Preserving:"
Take a look at the section titled:
"If you notice the following error in the sync log, then set MVFS to preserve case by navigating to and settingCase Insensitive MVFS and Case Preserving:"
On this page.
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.team.connector.scm.cc.doc/topics/t_sync_tshoot.html
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.team.connector.scm.cc.doc/topics/t_sync_tshoot.html
Comments
Peter Vohmann
Jul 26 '13, 3:36 a.m.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