I have a very strange error running the cleartool lsview command under UNIX (version 7.1.2.12).
The command works in general but for some users (!) it gives the following error message :
cleartool: Error: No matching entries found for view tag "user_*".
I encountered this error first in a Perl-script but it is reproducible on the command line as well. I try to do something like :
cleartool lsview user_\*
Where user is the user name. For most users (like myself) cleartool will list my views that start with my user name and are followed by an underscore.
For some other users the command will return a list with their views but in addition it will produce the error message mentioned above. My script obviously checks for ClearCase errors and stops working. If I left out the underscore (any underscores in the pattern!) the error message is gone.
Is there anything I need to be aware of when querying the views of a user? The IT told me to do :
cleartool lsview|grep "user_"
which would work without an error message but I want to understand why the error comes up.
Thanks for reading so far.
I always use a grep, but I just test in command line (on Windows). This works:
cleartool lsview prefix_*
In other word, I never had to escape the '*'. This doesn't work:
cleartool lsview prefix_\*
cleartool: Error: Invalid view tag: "prefix_\*".
It can depend on how the shell will interpret the '*', as in this similar bug.
Under Unix, you might want to avoid a premature interpretation of the '*' (wildcard expansion) with double-quotes:
cleartool lsview "prefix_*"
The OP user2606240 reports in the comments:
As soon as the _ is in the view name I get the error message.
As far as I understood the registry and registered views that should not be the case.
I think I'll just implement the grep after lsview and live with it.
Related
Background
I have a directory element in clearcase that has a version tree as shown below:
VIEW_NAME --> Version 0 --> Version 1
I am trying to remove Version 1 of the directory so that the version tree looks like this:
VIEW_NAME --> Version 0
Problem
I have tried to use rmver to accomplish what I want. However, I am not allowed to invoke rmelem at all, which rmver uses as part of the command. I know this because I have faced the following error:
ERROR: User myusername cannot use rmelem. Use rmname instead.
cleartool: Warning: Trigger "TRG_NO_RMELEM" has refused to let rmver proceed
cleartool: Error: Unable to remove versions of ".".
Attempted Solution
I have ran a search through the man pages of rmver and rmbranch for a possible option to use a rmname version of either command, however there is nothing in either man page. This lack of an rmname like functionality in either command has lead me to ask the question:
Question
Is there a version of the rmver command that uses rmname as part of its core execution instead of rmelem?
No: rmver would never use rmname.
As mentioned here
Removing an element name from its parent directory (cleartool rmname) does not affect the element itself, but two other types of a removal operation do irrevocably affect an element. Be very conservative when performing these operations (rmver, rmelem)
Since:
rmver deletes both the version object in the VOB database along with associated metadata and the corresponding data container in a source storage pool.
There is always a rmelem involved (not for the version itself) but other metadata elements associated to the version that need to be removed.
If you really needs to remove that version, you might consider disabling temporarily the trigger, following "How to disable a trigger in a VOB or determine if an existing trigger is already disabled".
Something like:
cleartool lock -obsolete trtype:<trigger type name>
I have a view, for some reason, it was named with a special character: "0x7f", at least I think so..
For example:
MyView123456 -> MyView'0x7f'123456
I can only found this view by
ct lsview #list all views.
And I found this "0x7f" when dump the outputs to a file.
And using vim.
Now I'm trying to delete this view totally.
I can unregistered and delete the view itself by -uuid.
But I cannot delete the view tag.
And I also found wildcard '*' seems not working.
Does anyone know how to delete this view tag?
P.s. I'm under Linux, and no GUI.
Try first if dome of the workaround described in "Removing ClearCase objects whose name begins with a hyphen", when using cleartool rmtag:
cleartool rmtag -- MyView*
Note the use of '--' in order to separate the command from its parameters
The wildcard being expanded by your shell, try and use it instead in the cleartool interractive session:
cleartool
> rmtag -- MyView*
In Linux shell, see if a single quote is enough:
cleartool rmtag -- MyView'0x7f'123456
# or
cleartool rmtag -- 'MyView0x7f123456'
I was able to create and remove a view with binary data in the tag using Perl. You have to use the OCTAL value of 177 in the strings.
I created my view using this command line:
perl -e '`cleartool mkview -tag myview\177tag /net/bullwinkle/export/vobstg/binarytag.vws`'
And I successfully removed that view tag using this command line:
perl -e '`cleartool rmview -tag myview\177tag`'
If the view was unique enough, you could also use (on Unix) or at least try:
cleartool rmview -tag `cleartool lsview 'myview*123456'`
There is another mechanism, if all else fails: you can edit the vob_tag registry file. This would require an outage as the registry file is loaded into the registry server's memory on clearcase startup and only re/written after that point.
The process is:
Stop ClearCase on the registry server
CD to /var/adm/rational/clearcase/rgy (Unix) or {CC Install dir}\var\rgy (Windows)
Back up the vob_tag file.
load the vob_tag file in an editor. (vi/gedit on unix, but I'd use notepad++ on windows)
locate the problem view tag (you may need to search on the global path or some other component of the name).
Make note of the path to the view.
Delete the line.
Start ClearCase on the registry server
unregister the view or retag it with an easier-to-access tag.
I'm trying to recursively delete some versions/files from a specific branch.
find delivers the right files. Now it would be up to rmver to remove the version but this gives me an error. I'm struggling with the syntax.
cleartool> find Component\Test -element "brtype(P_Testing_device)" -exec "rmver -f \"%CLEARCASE_PN%##\main\G_Testing_device\P_Testing_device\LATEST\""
cleartool: Error: Extra arguments: "%CLEARCASE_PN%##\main\G_Testing_device\P_Testing_device\LATEST\"
What's wrong with that?
How would you recursively delete versions from a Branch?
First don't if you can avoid it. rmver, as I explain in "How do I undo a checkin in ClearCase remote client", is very dangerous.
If you have hyperlinks attached to the versions you are removing (definitively from ClearCase), like merge links (deliver or rebase links of your are using UCM), you risk ending up with many "dangling hyperlinks", which is not good.
Second, I would try first:
find Component\Test -element "brtype(P_Testing_device)" -exec 'rmver -f "%CLEARCASE_PN%##\main\G_Testing_device\P_Testing_device\LATEST"'
To rule yout any issue with weak vs. strong quoting (as in "CLEARCASE_XPN not parsed as variable in clearcase command")
If that doesn't work, I would recommend finding all the right versions and putting them into a file, then piping the content of that file to a cleartool rmver.
A much safer route is to cleartool lock -obs the branch, making it non-modifiable and invisible for the future version trees.
I have a question about clearcase, someone helped me on some issue in clearcase, he used a command as follow: echo " " > xxx.log and
cleartool co -nc filename
what does this mean?
When you have a file which is "checkedout but removed", as described in ct ls:
The element was checked out in this view, but the view-private file was subsequently removed.
You may have deleted the file.
A solution to restore that file is to checkout it again, but if you do that directly, ClearCase would complain about being unable to access said file (because it isn't physically there anymore).
Hence the:
echo " " > afile
You need to have some content in that file in order to make a cleartool command on it.
So even if its content is a bogus one, it at least allows you to proceed.
Then, you can checkout it again (-nc means without comment, but it also means "takes the previous comments used on the current checked out version)
cleartool checkout -nc afile
Another way to restore it is to uncheckout the file:
cleartool unco afile
That will also restore its content.
The first command writes a space to xxx.log; echo is a shell command and has nothing to do with clearcase. The second command checks out filename without comments. These two commands seem to be pretty unrelated, unless there something else you haven't told us.
Just a tip:
'echo' might to used to clear xxx.log file.
co - stands for check out filename,
nc - stands for no comments
Might be helpful: http://www.yolinux.com/TUTORIALS/ClearcaseCommands.html
So I'm writing a script at work where I have to go through all the projects in a ClearCase vob, look for a file and parse some info from said file.
Naturally, I wouldn't want to load every single project so I'm using cleartool to retrieve the unloaded files.
First, I'm using the find command to locate the files. This was my first attempt:
root>cleartool find C:/viewpath -name file.txt -version "lbtype(Version-label)" -print -nr
Viewpath is the path to the project where I'm currently looking for the file. The file I'm looking for is file.txt on the version specified by Version-label.
This gave me no result whatsoever, even though I knew file.txt existed on that version.
I figured out it was looking through an old version of the directory, the latest on the main-branch, which was before file.txt was added to the directory. I tried this instead:
root>cleartool find C:/viewpath##/Version-label -name file.txt -version "lbtype(Version-label)" -print -nr
And got this result, which was what I was looking for
C:/viewpath\file.txt##\main\branch\41
So now that I knew where I could find the file I tried to get it.
root>cleartool get -to savepath C:/viewpath\file.txt##\main\branch\41
Which gave me this result
cleartool: Error: "C:/viewpath\file.txt##\main\branch\41" does not exist, or is not a ClearCase version, or is a checked out version which was removed.
Also tried
root>cleartool get -to savepath C:/viewpath\file.txt##/Version-label
With the same result
I can get files added to the directory when it was still on the main-branch, so it is still searching through the directory on the main-branch, where file.txt is nowhere to be found.
How do I tell it to look through a version of the directory from after it was branched from main?
I would really recommend for you to try those same commands in a dynamic view.
As illustrated here, a dynamic view gives you access to extended path (the file##/branch/version syntax), which means command like get will work.
You have in this question an example of search (cleartool find) using extended paths.
As explained in "In ClearCase, how can I view old version of a file in a static view, from the command line?", you can browse (as in 'change directory to') the various extended paths of a file in a dynamic view.