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)
Related
I am not been able to check out file in this specific pc because it compalins abt
cleartool error: type manager "text_file_delta" create_branch operation.
cleartool error: unable to create a branch request by -mkbranch option in config spec.
cleartool error: unable to check out
config_spec:
# ONLY EDIT THIS CONFIG SPEC IN THE INDICATED "CUSTOM" AREAS
#
# This config spec was automatically generated by the UCM stream
# "space_reload_CA" at 2013-09-06T16:13:58-04:00.
#
# Select checked out versions
element * CHECKEDOUT
element "[03d13482d8a611dc9c17000183b043eb=/space_tff]/.../..." -nocheckout
element "[03d13482d8a611dc9c17000183b043eb=/space_tff]/.../..." -nocheckout
element "[975cd291464411df86be0001843ab215=/space_tff/.../..." .../space_reload_CA/LATEST
element "[975cd291464411df86be0001843ab215=/space_tff/.../..."
-mkbranch space_reload_CA
element "[975cd291464411df86be0001843ab215=/space_tff/.../..." /main/0 -mkbranch space_reload_CA
end ucm
#UCMCustomElemBegin - DO NOT REMOVE - ADD CUSTOM ELEMENT RULES AFTER THIS LINE
#UCMCustomElemEnd - DO NOT REMOVE - END CUSTOM ELEMENT RULES
# Non-included component backstop rule: no checkouts
element * /main/0 -ucm -nocheckout
#UCMCustomLoadBegin - DO NOT REMOVE - ADD CUSTOM LOAD RULES
# Component selection rules...
That looks like the IBM article "Element already has a branch of type"
The actual error is:
%>cleartool co -nc a.txt
Created branch "branch" from "a.txt" version "\main\1".
cleartool: Error: Element already has a branch of type "branch" ("\main\branch").
cleartool: Error: Unable to create branch requested by -mkbranch option in config spec.
cleartool: Error: Unable to check out "a.txt".
The cause can be:
a time issue (cause 1, 2 and 4 below): The OP user2370590 mentions a possible remedy:
rebooting will resolve such type of issue
a syntax error issue (cause 3 below)
Syntax errors are usually the cause, except in your cause this is an UCM view, meaning its config spec is automatically generated by ClearCase.
Just to be sure, type:
cd /path/to/your/view
cleartool chstream -generate
cleartool setcs -stream
That will force the config spec of your view to be regenerated according to the configuration of your Stream.
And try again your checkout.
Cause 3:
The error will occur due to a number of config spec syntax problems:
Incorrect spelling of scope, pattern, or version-selectors.
For example CHECKEDOUT or LATEST or label names or branch names
Incorrect ordering of the scope, pattern, or version-selector.
For example forgetting to include a LATEST rule that references a -mkbranch rule.
Metadata "types" not created but referenced in config spec.
For example a -mkbranch rule referencing a branch type that does not exist.
A directory is listed using windows style slashes("\" instead "/" ) in Unix/Linux systems
(Note: in a config spec, always use "/": it is easier, and it works both on Windows and Unix.
Solution 3: Fix syntax
Ensure the syntax is correct in the config spec.
Cause 1: time sync issue
This error is caused by the view server and VOB server time not being in sync.
If the time (clock) on the VOB server is greater then the view server this error will happen as the version is created with a time stamp that is seen as in the future by the view server and thus will not be loaded (snapshot view only).
Solution 1: Fix time
Correct the time on the view and VOB server so they are in sync.
Review the operating system instructions on how to modify the system time.
Cause 2 VMware issue
This error can happen when using ClearCase on a VMware® hosted machine.
The cause of the error is related to the time setting on the VMware server. If the time on the VMware server is behind that of the VOB server, then the mkbranch error will occur.
Solution 2: Fix VMware time
Ensure the time on the VMware server is in sync with the VOB server.
The following command is one method that may be used on the VMware server to synchronize the time with that on the VOB server.
net time \\vob_server_name /set
Cause 4: Replica migration
In one case, the exporting VOB had been moved from one host to another. Instead of following the move procedure outlined in the Administration Guide, the VOB was copied to the new host.
This left the VOB active in two places. One developer created a branch type in the original location. After starting to work with the copied VOB at the new location, the developer detected that the copy did not contain the latest mkbranch operation. The developer decided to run the mkbranch operation again.
The importing site got the synchronization update packet with the first mkbranch event and imported it.
Then the packet with the second mkbranch event arrived but could not be imported because the branch already exists; hence the error.
Solution 4: Fix replica
This is divergence as both replicas, the sending and the receiving site, do not agree on the date and time of the mkbranch event.
One of the replicas will need to be removed and recreated. Which one to remove depends on the size of the replica family, the synchronization pattern in use and the willingness to lose data in that replica.
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.
I created a view using cleartool command.
cleartool mkview -tag code-count-view -nsh $ccViewspath+$ccViewName
But as it is added as part of script while executing next time , i am facing issue says that view exists already
How to verify whether view name already exists or not?
A simple cleartool lsview yourViewTag is enough to check if a dynamic view exists.
Which is your case (your cleartool commands creates a dynamic view)
For a snapshot view, you would have the additional issue to find/check the root directory of said snapshot view, which isn't always easy.
That's a problem we've already faced in ClearEnv, our ClearCase add-on tool that automatically creates working environments by predefined templates, so I can share my insights.
My advice: do the following checks:
Check in ClearCase registry if the view tag is already exist
Check if target folder is already exist
You also have to do further checks if you want to create shortcut to ClearCase explorer and could be that there are more scenarios you have to deal with
Can the project manager force cancellation of checkouts of files/directories made in any view/stream/project? How?
A ClearCase administrator can force all files of a given view to be considered as "not checked out" (which is the equivalent of canceling their checkout status), with cleartool rmview:
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
You can get the uuid by grepping the user in the output of:
cleartool descr -l vob:\aVob
See technote "Removing checked-out references of a view from a VOB".
It will work for any view (snapshot or dynamic views, base ClearCase or UCM views)
I would recommend limiting that command to a specific vob.
Anyway, that doesn't concern the Project manager unless he/she is also a ClearCase administrator (ie, he/she is in the same group than the ClearCase administrators group on Windows, or if he/she is root on Unix)
Regarding a cleartool unco (which you can attempt on a dynamic view only), keep in mind if will only work for:
Version creator
Element owner
VOB owner
root (UNIX and Linux)
Member of the ClearCase administrators group (ClearCase on Windows)
Local administrator of the ClearCase LT server host (ClearCase LT on Windows)
So, unless your project manager has created the Vob in which those checked out files are managed, he/she won't be able to undo checkout them.
As commented below, all checkout files of the associated vob \avob are no longer considered checked out (their status is reset, not their modified content, which is untouched).
In order to restore those checked out files, a user can:
for a snapshot view, list hijacked files (as in this technote)
for a dynamic view list eclipsed files (see technote on eclipsed files)
Each filename found can be piped to a clearcase checkout command.
So restoring the checked out files is fairly easy for a given view and vob.
You can't if it was checked out in a snapshot view. You may be able to if it was checked out in a dynamic view. You can use Find Checkouts to find checked out files and attempt to undo the checkouts from there.
Ideally, if it is a view that is accessible by someone with higher privilege, e.g. Clearcase administrator who possesses the VOB owner account, it is best to ask him to perform the checkin (if you are sure the file can be checked in) or a saving of the checkedout file followed by a "cleartool unco".
If it is not the case, the command
cleartool rmview -force -uuid (uuid_of_the_view) -vob <vob-tag-where-checkout-is>
should do the trick as mentionned previously by VonC.
However, be aware that this command cancel ALL the checkout in .
So if you have say :
\avob\file1.c
\avob\file2.c
Say both files are checkedout by the same view of the same user and you want to uncheckout only file1.c. The "cleartool rmview" command described above cancels ALL the checkout in the VOB. So file2.c will also be uncheckedout.
The good news is that the checkedout version will not be lost as they will stay locally in the absent user's view. He will be able to access them once he is back.
There is still another strategy how to handle other persons checkouts as an administrator. Gain access to the users snapshot view. If the computer is reachable, mount the snapshot location and use it as yours. In this case you may even checkin these checkouts as you see the changed files. Is the computer is unreachable, you can construct a new view.dat with the view UUID and populate your view with a cleartool update command for the critial files and directories. Changes in directory versions you will see and be able to checkin, file element changes are not reachable, so you have always to unco file versions.
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 ""