we are using snapshot view (UCM).
While we tried to add source control a folder it fails with following error.
Rational ClearCase Explorer
---------------------------
Error adding 'D:\cc_view\IS-Dev1\Impl\Install\ViewDeployment' to source control.
Checkout is currently disabled for element "D:\cc_view\IS-Dev1\Impl\Install". An update appears to have been aborted or errors were encountered during an update. An update must be performed on the element to enable a checkout. Checkout is currently disabled for element "D:\cc_view\IS-Dev1\Impl\Install". Its config spec rule information is currently unavailable due to either an aborted update or an update in progress.
We have updated the view once again and stop and start the clearcase related services.
But still no improvement. When we look at properties of view-> advanced tab . it show Load state: Update cancelled.
I think this state may play a role. How to solve this and allow it to add to source code control?
You need to make sure to launch the update at the root directory of the snapshot view (above the vobs), because UCM might complain because of the configuration change.
If the Stream has been rebased, then an update would ask for you to accept the new configuration and launch a full update, but only if done from the root directory of the view.
Check also the logs of those updates (file *.updt in the root folder of the view), any error in it would mean a "Update cancelled" for the view.
A way to get a full update in your case would be (still at the root folder, as in this technote -- for CCRC but also valid for a full ClearCase installation):
cleartool setcs -current
Previous update or checkout is uncompleted. You have to update your snapshot view. You can run
cleartool setcs -current
OR
ClearCase Explorer->(on left panel--snapshot_name) right click-> Update View->Yes
that operation take a long time. That operation completed after this problem fixed.
Warning: Dont stop updating processing. You shouldn't start this operation while starting. Because you cant do progress while clear case updating to view.
Related
When I am trying to check in a file in ClearCase, I receive an error:
cleartool> ci -nc 1234.txt
cleartool: Error: Branch not consistent with stream attached to current view.
cleartool: Error: Unable to check in "1234.txt".
Does anyone know what's causing this? It started happening this morning.
So far, I have synchronized the stream and the view with no luck. Please help.
If so, what activity? - tied to a CC activity that is associated to an old stream, CQ activity is tied correctly
That means it is an UCM project with CQ integration.
When I look under version tree of this element, the element checkout is under a branch that is different from the stream the checkout was initiated from??? How can that happen?
That can only happen if the view used for the checkout had a different config spec than the one generated from the UCM stream. It is best to undo that checkout, and start again in the proper view.
Well, all I can do is add questions:
How old is the checkout?
Is it on a NON-UCM branch?
If so, when was the component added to the stream's configuration?
If you describe the version, is it associated with an activity? If so, what activity?
Has anything else "odd" happened to the view of late? (restored view from backup, etc.?)
What you're probably going to need to do is do a ct unco -keep. This will undo the checkout and make the view look at the version selected by the current stream configuration. Then
Set an activity
Check out the file again
Verify that the version created is on the current stream's branch
Copy the .keep file to the checked out file
Check it in.
As I see it, just create another new view on required Stream and copy the file into it.
I am getting below error while updating the view.
Problems were encountered while retrieving view synchronization and data.
Clearcase CM server error: Unable to access "vob name" : unknown error in vob
Clearcase CM server error: Error 2 config spec load rule problems encountered
How to troubleshoot that error message?
You need to access the logs (both locally or on the server) to know more.
It used to be cleartool getlog (ClearCase 7.x, even for CC 8.x)
cleartool: Error: Checkout is currently disabled for element "element_name".
Its config spec rule information is currently unavailable due to either an aborted update or an update in progress
That is similar to an older CC (7.0.x) described in this technote:
Possible cause for symptom 1:
If an update, rebase or deliver operation is not currently in progress for the view in question, the error can often be attributed to the view being out of sync with the stream.
Try:
cd /path/to/snapshot/view
cleartool setcs -stream
Possible cause for symptom 2:
Hijacked nocheckout means that the version hijacked in the view is no longer the version the config spec selects from the VOB.
Rename the hijacked file and update the view.
Check out the version from which the file was hijacked.
Copy the hijacked file over the checked-out version.
Merge from the current version to the checked-out version.
The version can now be checked in.
Possible cause for symptom 3:
Per the error message explanation noted above, the problem may be caused by an issue with the view's config spec or an aborted or incomplete view update.
Try:
cd /path/to/snapshot/view
cleartool setcs -current
(original answer)
It can be a right issue, as illustrated by this thread.
Check group permissions on user and on those two VOBs.
Do you rely on the CLEARCASE_PRIMARY_GROUP environment variable?
If so, check the value of the user performing the update.
Compare the rights of the vob with the ones for your current snapshot view that you are trying to update:
cd /path/to/snapshot/view
cleartool lsview -l -full -pro -cview
If the CLEARCASE_PRIMARY_GROUP is not set properly, it is easier to:
set it to the right group (ie the primary group of the vob, or one of the secondary groups)
delete and recreate your view.
(if you do not want to delete/recreate your view, you can fix_prot it)
I have a huge clearcase snapshot view including about 10 VOBs, and it takes more than an hour to update the whole view.
Now I'm trying to change the config spec a bit to select several file elements with another timestamp. But by default, changing config spec will trigger a whole view update which is really slow. What I need is just to update the file elements with the updated timestamp.
I read through the official document about cleartool setcs, and also googled some time but it seems impossible. So Here's my question. Is it possible to change config spec of a snapshot view but only update partially?
Actually I also got a workaround here.
I opened the snapshot view in ClearCase Explorer, changed the config spec, clicked OK to update, and then cancelled after the update started. After that, I just updated those selected file elements.
The workaround was OK just for readonly. But I could not checkout/checkin because of the abort of update. The following error popped up when trying to checkout. So I had to update the whole view again.
An update appears to have been aborted or errors were encountered during an update. An update must be performed on the element to enable
a checkout.
Hence, here's another question. Is there any "brute" way to avoid the error for the workaround, since I know the config spec change won't affect other elements?
Besides, any other idea or workaround to solve my problem is absolutely welcomed.
One workaround would be to use a dynamic view (at least to try different config specs and check that the right versions are selected, before using that config spec on a snapshot view if you must.
Another approach is to use 10 snapshot views, one per Vob, because you can update them in parallel, making the all process faster, and starting some of the checkouts faster
I am trying to understand how long ClearCase operations take after performing the add to source control operations.
If I am working through a CCRC snapshot view and I add a file to source control, how long will it take for the changeset to be updated with the new line, and how long until the operation completes will the new file be available under a dynamic view pointing to the stream that the file was checked into?
Is there any way to speed up that process by invoking a manual update of the dynamic view or something?
Regards,
Andrew
how long will it take for the changeset to be updated with the new line
As soon as you checkout a file, selecting an activity, it will update the chenge set of said activity immediately.
A dynamic view would reflect that file only after you check in (through your web snapshot view in CCRC), and that update would also be near instantaneous.
To speed up, you can refresh the dynamic view, or do a cleartool ls in the directory you want to see updated.
In each case, when you are doing a checkout or a checkin through CCRC, you are posting an http request to the CCRC server which in turn complete the operation with the ClearCase Vob/View server.
So once the checkout/checkin is completed, any other ClearCase view (CCRC or not) would be ready to reflect the changes.
The only part which takes time is the communication between the CCRC client and the CCRC server. That server being usually on the same LAN as the ClearCase server, the ClearCase command itself executes fairly quickly.
"fairly quickly" turned out too slow for the OP's need: a postop trigger on checkin.
That trigger use a ClearCase dynamic view on the server side, and has to introduce a sleep on the element checkin (on mkelem) in order for the second call of that trigger (on the parent directory being checked in) to properly detect the new created file.
Theoretically, it should be instant. As soon as the add finishes, the dynamic view should see the new file. In reality, it might take longer due to the nature of ClearCase and its view processes.
Every view has a process running on the view server (local or remote), and this process needs to query the VOB server to get the changes.
In our ClearCase environment, we see many lags that are probably the combination of a loaded server and network traffic.
Bottom line - should be quick (seconds), but not instant. If it takes longer, you should try and see what might be slowing the processes down.
When I try to 'rebase' my stream in clear case, I get the 2 options : 'Resume rebase' and 'Undo rebase'.
But both of them give me errors. It seems a previous rebase failed and left the stream in a corrupted state.
How to solve this?
I tried stopping and starting ClearCase but no luck.
EDIT: the error is :
IDispatch error #14083
Execution of a hook failed during the action Complete. It was the ACTION_COMMIT hook attached to the UCMUtilityActivity "CR00155721".
The reason for the failure was:
Trouble communicating with VOB database: "\Alerts_Proj".
Check database log on VOB host "123yyyyy.com".
Could not perform requested operation: a UCM/ClearQuest data
inconsistency may exist:
ClearQuest "UCMUtilityActivity" record "CR00155721" is linked to a UCM object
that can not be found.
Unable to complete the rebase activity in ClearQuest.
Unable to undo set of integration activity.
Unable to complete integration.
FYI I've also seen this happen when the "CQIntSvr11.exe" fails. It seems to occur when you need to use the application on the same machine with different users (e.g. admin and developer account).
If you kill the process using task manager and then retry the operation the IDispatch 14083 should stop and then you can use your stream again.
One solution might be deactivating the trigger, but this could be put by the ClearCase-ClearQuest link and not be possible without severing completely that link.
So you can start by checking out this IBM technote with your ClearCase administrator:
This error occurs because the UCM project VOB and associated activities have been removed, ClearQuest is still looking for this information and needs this information to remove the defect.
This issue is the result the ClearCase items being removed before the ClearQuest defects and project.
Solution
To resolve this issue perform the following to fix the Activity so it can be deleted:
Browse to the ClearCase utils directory:
c:\program files\rational\clearcase\etc\utils
Run the following command from a command prompt:
Note: This command cannot be performed in the GUI
squid_patch <DBNAME> -activity ucm_vob_object ""
Note: It will display an advisory message, but it will change the field in ClearQuest.
Delete the ClearQuest record.
Remove the UCM project with the following command:
squid_patch <DBNAME> -project ucm_vob_object ""