I have an issue with ClearCase I was trying to check out a file from the dir by using ct co -nc file name, but I am getting the following error:
cleartool: Error: branch type "test1" not found in VOB "/dir/file" and no global type definition can be found.
cleartool: Error: Unable to create branch requested by -mkbranch option in config spec.
cleartool: Error: Unable to check out "file".
But when I was trying to check out another file from dir I am able to do them. I am only getting the problem to check out that file.
Can anyone help me how can I overcome this error?
This looks like a config spec using a branch named "test1" in a selection rule (element ... -mkbranch test1) which was not created first.
So first, check what the config spec looks like:
cleartool catcs
See also what the config spec are for the files in the parent folder of that file:
cd /path/to/§parent/folder
cleartool ls
See if using cleartool mkbrtype would help:
cleartool mkbrtype -c "test1 branch" test1#/vobs/avob
(I use the Unix syntax, judging from your previous config spec)
Looks like "test1" branch type does not exist in the vob.
Create a branch using ct mkbrtype. Run the following command form the folder where file is present
ct mkbrtype -nc test1
As the error is occurring only for one file, the config spec should have selection rule only for that file. Can check this using
ct catcs
Note:- When adding a branch rule in config spec, Always check the brtype exists with that name.
Related
I'm running this command :
cd into view directory
cd into the relevant folder
cleartool findmerge rvnDataPathEgressProcessor.cpp##\main\RavenAppMain_Integ\RavenApp1.5\RavenApp1.5.0.0_Integ\RavenApp1.6.0.0_Integ_OBS\RavenApp1.5.2.0_Integ\RavenApp1.5.5.0_Integ\14 -fversion rvnDataPathEgressProcessor.cpp##\main\RavenAppMain_Integ\RavenApp1.5\RavenApp1.5.0.0_Integ\RavenApp1.6.0.0_Integ_OBS\RavenApp1.5.2.0_Integ\RavenApp1.5.5.0_Integ\aviv.sharon_RavenApp1.5.5.0\15 -print -whynot
I'm getting this error:
cleartool: Warning: A version selector is required, not a pathname:
"rvnDataPathEgressProcessor.cpp##\main\RavenAppMain_In
teg\RavenApp1.5\RavenApp1.5.0.0_Integ\RavenApp1.6.0.0_Integ_OBS\RavenApp1.5.2.0_Integ\RavenApp1.5.5.0_Integ\aviv.sharon_Ra
venApp1.5.5.0\15".
No merge "rvnDataPathEgressProcessor.cpp" [no version "rvnDataPathEgressProcessor.cpp##\main\RavenAppMain_Integ\RavenApp1.
5\RavenApp1.5.0.0_Integ\RavenApp1.6.0.0_Integ_OBS\RavenApp1.5.2.0_Integ\RavenApp1.5.5.0_Integ\aviv.sharon_RavenApp1.5.5.0\
Any idea how to fix this?
A cleartool findmerge requires pname:
One or more file, directory versions, or both; only the specified file versions and the subtrees under the specified directory versions are considered.
If rvnDataPathEgressProcessor.cpp##\main\RavenAppMain_Integ\RavenApp1.5\RavenApp1.5.0.0_Integ\RavenApp1.6.0.0_Integ_OBS\RavenApp1.5.2.0_Integ\RavenApp1.5.5.0_Integ\aviv.sharon_RavenApp1.5.5.0 is not an existing extended pathname, there is no version to be found, and that would explain the error message.
Try finding a view which already select the destination version, and do a:
cleartool descr -l rvnDataPathEgressProcessor.cpp
That would give you the exact and full extended pathname.
The OP reports the second argument should be the version only, without the file:
\main\RavenAppMain_Integ\RavenApp1.5\RavenApp1.5.0.0_Integ\RavenApp1.6.0.0_Integ_OBS\RavenApp1.5.2.0_Integ\RavenApp1.5.5.0_Integ\aviv.sharon_RavenApp1.5.5.0\15 without the rvnDataPathEgressProcessor.cpp##.
I wish to merge an activity with my activity, the former activity has new directories and new elements.
I am getting the following error on issuing a merge with the following command
ct findmerge activityname#/vob/** -fcsets -nc -merge
The errors are as follows in 2 cases
Case1: No new elements created directly the merge command
Errors
/vob/**/Build.mk [checkedout but removed]
/vob/**/file1 [checkedout but removed]
/vob/**/file2 [checkedout but removed]
/vob/**/file3 [checkedout but but removed]
cleartool: Error: Checked out version, but could not copy data to "/vob/siren/oam/sdh/pkg/Build.mk" in view: Permission denied.
Correct the condition, then uncheckout and re-checkout the element.
Case2: I created the elements and the directory structure still the same error
Note: There are no errors for the elements which already exist in the vob
Try again your findmerge activity (as described here), but this time, without using cleartool setview (meaning without using a path starting with /vob, the mounting point for the dynamic view set by cleartool setview).
Always use the full path of the destination dynamic view (the one where the merge occur): as I told you in your previous question, cleartool setview is nothing but trouble.
Use:
cd /view/yourDestinationView/vobs/siren
ct findmerge activityname#/vob/** -fcsets -nc -merge
I am trying to label all the elements within a branch of a view, but some of the elements do not get labeled and instead give me a "No such file or Directory" error. I can see the files that generated the error in my command window, but they are highlighted in red. It seems like these files are not there and are thus generating the error. How can I remove these "files" from the view so that the labeling can continue and not generate errors?
Say that bolded words represent red highlighting. This is what I see:
file1 file2 directory1 directory2
Here is how my code is structured in my shell script:
cleartool mkview -tag $VIEWNAME ... (etc.)
cleartool setcs -tag $VIEWNAME configSpec.txt
cd /projectDirectory
labelname=`date "+%b-%d-%y"`
cleartool mklbtype -nc $labelname
cleartool mklabel -recurse $labelname /projectDirectory
The script starts recursing through the file tree from the projectDirectory. When it encounters file1 or directory1, I get the "No such file or directory" error. Otherwise, for file2 and directory2, the labeling occurs properly.
So, my question is this: How can I use the mklabel command or some other method to label all the files that are not highlighted in red?
You must first know the exact status of the "files in red"
For that, go in a shell to their parent folder, and type:
cleartool ls
That will give you their status (eclipsed?, private? other?), which will explain why the label cannot proceed.
Possible causes:
the files are symlinks
the files have spaces in their names (that shouldn't be the case here: cleartool mklabel should support that case)
the files are in the lost+found folder (solution: exclude that folder from your view with a -none selection rule)
Note: if an element isn't selected (no version selected and Rule: -none), then a recurse mklabel is supposed to generate that error message, but that won't prevent the label to be set on the other elements version.
So that error message should be safely ignored.
Currently, I have to wait for a symlink error when updating a clearcase view. I then take the name for the broken symlink and search for it specifically.
is there a way to find all broken symlinks, without necessarily knowing the name?
how to find one at a time:
cleartool> cd C:\cc_view\view_name\source_app
cleartool> find -all -type l -name "missing.link.name" -nxname -print
You shouldn't need a -all in your find query.
Broken symlink in a snapshot view update are element which are visible:
cleartool find . -type l -name "missing.link.name" -nxname -print
You can execute that command in a DOS session ("cleartool find", instead of a cleartool one "cleartool> find"): that allows you to redirect the result in a text file and parse the result.
The IBM article "How to find broken (orphaned) Symlinks" can also help.
Cause
User renamed the target, so the symbolic link is pointing to a non existing target.
After the rename of the versioned target file (a.doc -> a.docx, done by ClearCase Explorer) I get the update error, that the symlink a.doc does not exist.
Unable to resolve symlink "filename.doc". The symlink target will not be loaded.
Where can I find the link itself (in which folder is it located?)?
How can I solve the rename (?) of the symlink?
Answer
To find and remove the symlink:
Use a dynamic view (snapshot views cannot load the missing links).
Run M:\viewtag\vobtag>cleartool find . -kind slink -print
Refer to the following technote for information about how to remove the symlinks as found in the output of the above command: "Unable to resolve VOB symlink":
A cleartool ls from the command prompt will show:
virt.46e5e94ff9024144ab0fe9ed432ce6e6 --> ../virt
virt.5043bcc7c8f44439938d634bd5ba9ac2 --> ..virt [not loaded]
The above symbolic link is to a resource outside of ClearCase, which renders the hyperlink invalid for use in UCM.
Resolving the problem
Remove the broken (dangling) link from the VOB to clear the error, using the cleartool rmname command.
Example:
cleartool rmname virt.46e5e94ff9024144ab0fe9ed432ce6e6
Using cleartool rmname allows you to preserve the symbolic link, but remove references
to it from future directory versions.
Symbolic links can be permanently removed using cleartool rmelem, refer to technote 1148781 for more details.
When I do "ct lsco -a" I can see that I have three checkouts. But they don't show up in xclearcase, and the directories aren't visible from the command line.
ct lsco -a | grep hendrixjl
--07-29T15:32 hendrixjl checkout directory version "/vobs/CORE/CORE_APPS/src/mapmgr_decoupled##/main/rel_core_0.5.0.0__int/fea__cr_54__0.5.0.0_decouple_map_manager/3/icondetails_decoupled" from /main/rel_core_0.5.0.0__int/fea__cr_47__0.5.0.0_ui_decouple/0 (unreserved)
--07-29T15:32 hendrixjl checkout directory version "/vobs/CORE/CORE_APPS/src/mapmgr_decoupled##/main/rel_core_0.5.0.0__int/fea__cr_54__0.5.0.0_decouple_map_manager/4/overlays" from /main/rel_core_0.5.0.0__int/fea__cr_47__0.5.0.0_ui_decouple/0 (unreserved)
--07-29T15:32 hendrixjl checkout directory version "/vobs/CORE/CORE_APPS/src/mapmgr_decoupled##/main/rel_core_0.5.0.0__int/fea__cr_54__0.5.0.0_decouple_map_manager/4/overlays/main/rel_core_0.5.0.0__int/fea__cr_54__0.5.0.0_decouple_map_manager/1/images" from /main/rel_core_0.5.0.0__int/fea__cr_47__0.5.0.0_ui_decouple/0 (unreserved)
[hendrixjl#BA-JBCP-HENDRIX CORE]$ cd /vobs/CORE/CORE_APPS/src/mapmgr_decoupled
[hendrixjl#BA-JBCP-HENDRIX mapmgr_decoupled]$ ls
Makefile ascope_translator common_decoupled displaySA_decoupled filters mgr_decoupled unit_test
[hendrixjl#BA-JBCP-HENDRIX mapmgr_decoupled]$ ct unco .
cleartool: Error: No branch of element is checked out to view "cc-svr:/data/cc_store/viewstore/hendrixjl/fea__cr_47__0.5.0.0_ui_decouple__hendrixjl_view.vws".
cleartool: Error: Unable to find checked out version for ".".
[hendrixjl#BA-JBCP-HENDRIX mapmgr_decoupled]$ ct unco icondetails_decoupled
cleartool: Error: Element name not found: "icondetails_decoupled".
[hendrixjl#BA-JBCP-HENDRIX mapmgr_decoupled]$
Those directories are checked-out in parent directories which are not visible/selected by your current view, probably because they have been removed (rmnamed).
That means the checked-out versions are not accessible from this view.
However, a potential workaround is to search for those same checked-out directories from the GUI "find checkouts" window: there you can select the checked-out element (file or directory) and select "undo checkout".
Another workaround is to go to the full extended path of that directory in a dynamic view: you will then be able to "cleartool unco" the directory.
cd /vobs/CORE/CORE_APPS/src/mapmgr_decoupled##/main/rel_core_0.5.0.0__int/fea__cr_54__0.5.0.0_decouple_map_manager/3
cleartool unco icondetails_decoupled
In any case, whenever you don't see an element, the first think to do is a version tree of the parent directory of that element, in order to check if the missing element has been rmname'd in one of the version of said parent directory.