RTC-ClearCase synchronizer requires ClearQuest credentiald although the UCM Project is not ClearQuest Enabled
![]()
Hi,
I have the following configuration:
UCM Project A (ClearQuest Disabled)
UCM Project B (ClearQuest Enabled)
Both projects contain component C1 and modify it.
Project B deliver C1 changes to Project A.
Then, I created RTC synchronized stream S1 to synchronize it include history (import baselines) with Project A's Integration stream.
All I need is to import ClearCase baselines, without synchronizing ClearQuest records or add anything to ClearQuest records.
Although Project A is ClearQuest Disabled, import stiil fail as it try to login ClearQuest.
1. Does it make sense that there is a ClearQuest login attempt in this scenario? Is it a bug?
2. If so, is there a way to cancel it?
3. If it is not possible to disable it, what will be written in ClearQuest defects during the import to RTC?
Thanks,
Amit.
|
3 answers
![]()
I am able to reproduce the error. In this case, syncing stream S1 should not try to login to CQ. (I will open defect for this).
For now, if you want to workaround the problem to make the sync succeed, right-click on sync stream "S1", Properties -> ClearCase Properties, Change the default value for "CLEARQUEST_*" so you can login to CQ. |
![]()
Yes. It is safe to run the import.
|
Comments
Hello Amit, would you elaborate on the ClearQuest Disabled project? I guess it would be one of:
A) the UCM project has never been CQ-enabled,
B) the UCM project has been CQ-enabled once, then it is disabled now, or
C) the UCM project has been CQ-enabled but is suspended.
Which one is your case?
Hi,
Hi Amit,
Unfortunately, it sounds like a bug. I'd encourage you to file a PMR.
Going back to your original question, I don't think it would make a change to ClearQuest defects while you import from UCM project A or project B. The synchronizer accesses ClearQuest system to look up headlines, descriptions, etc.
If you make a change in the RTC stream and synchornize it out to ClearCase, it would create a new CQ record, anyway.