I am not able to checkout any element in Dev stream in Clearcase from any user except the admin user. I am getting below error :
No permission to perform operation "checkout".
Must be one of: member of object group, object owner, VOB owner, member of admin group.
I added the user group to the Primary group of clearcase in Windows, but I am still facing same issue.
Assuming a regular ClearCase (not CCRC with automatic or web view), type in your view:
cleartool lsview -l -full -pro -cview
Check if if the primary group is correct.
If not, take note of the global path (which should be like an network UNC path \\<aServer>\path\to\view\storage.
If not, in a regular CMD session:
set CLEARCASE_PRIMARY_GROUP=<aGroup>
doskey fp=c:\Rational\ClearCase\etc\utils\fix_prot.exe -force -chgrp "<aGroup>" -chown <aLogin> $*
fp -rec -chmod 775 \\UNC\Path\to\view.vws
fp -root \\UNC\Path\to\view.vws
Replace \\UNC\Path\to\view.vws by the global path you have seen in the first step (the lsview one), as mentioned above.
Replace <aGroup> by the primary group name, and <aLogin> by your Windows login.
Make sure your user is part of that group.
Related
I tried ls command, but it doesn't actually show permissions for VOB elements. I cannot understand what command to use in order to see the permissions. Can somebody help me?
Generally, you can use cleartool describe:
cleartool descr -l yourFile
# for the vob itself:
cleartool descr -l vob:\vobtag
The second command is important, as it would list the primary and secondary groups associated to the vob: you must have your CLEARCASE_PRIMARY_GROUP set to one of those groups in order to access the vob.
Using fmt_ccase, you also have access to the filesystem object permission:
%[permissions]p
File system objects: Displays the object's permissions using the standard "rwx" notation.
cleartool desc -fmt "%[permissions]p" .
I have some files and directories out of which few are already checked out and few are not.
To check out those uncheck out files I am running recursive checkout:
ct co -nc ./*
Which gives below message for already checkout files or directory:
cleartool: Error: Element "abc/xyz" is already checked out to view "pqr".
Is there any way I can avoid performing ct co on already checked out files or directories?
First, you can check if you have the same issue when applying my old method "How do I perform a recursive checkout using ClearCase?".
cleartool find somedir -type f -exec "cleartool checkout -c \"Reason for massive checkout\" \"%CLEARCASE_PN%\""
(which is mirrored by the IBM technote swg21122520)
The other option is to:
first find checked out files (see "How to find all checkedout files with ClearCase cleartool?", without the -cview option, in order to list checked out files in all views)
redirect that find into a file
Then you can replace the -exec directive above in order, for each \"%CLEARCASE_PN%\" found, to:
check if it is listed in the checked out files found in the previous point
if it is not, proceed with the checkout.
In short: a two-step process.
Four months ago a colleague had a shapshot view that he deleted from the file system while there were still directory checkouts on a certain branch, say branch 'A'. Now some of directories are obsolete and need to be rmname'd from other views, but this cannot happen apparently while they are still checked out on branch A.
What is the most direct way to unco these directories on branch a?
You can unregister completely this view (even if the actual view is gone from the filesystem).
See "ClearCase: Is it possible to cancel checkouts not made from your own view?":
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
That will trigger, as a side-effect, the removal of the checkout status of any file checked out by this view (referenced by its uuid) in this vob (the -vob option).
See more at "How to delete clearcase views created by other users?":
cleartool lsview -l theViewToRemove # get its uuid
cleartool rmtag -view theViewToRemove
cleartool unregister -view -uuid uuid_of_viewToRemove
You even can use the nuke_view.pl script.
Now some of directories are obsolete and need to be rmname'd from other views, but this cannot happen apparently while they are still checked out on branch A.
As I mention in "How do delete a file in ClearCase?", even if you don't unregister the view, you can still remove a file from a branch, even if it is checked out in another branch.
You simply need to do it from the command-line:
cleartool rmname -force /path/to/file
Eric Schnipke proposes in the comments:
(1) cleartool lsview -l theViewToRemove to get the view's UUID and then
(2) cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob to remove the view and offending file version.
I tried to create a baseline today and ClearCase Explorer crashed (seemed to be after it was finished, but evidently it wasn't.)
I tried to recreate the baseline and it gives me an error saying there are some that are "in_progress" so it can not proceed.
I removed the baseline, and I am trying to remove the "in_progress" label types.
When I remove the lbtype, it says that a directory is locked.
I did an lslock -all and removed the locks on a project and a baseline and now there is nothing listed when I do an lslock -all.
I tried to remove the "in_progress" lbtype and it is still saying that something is locked. Is there another way to find out what is preventing it from working?
I know this may be confusing, so if any clarification is needed, I am willing to update my question.
"ct lslock -all"
--09-09T09:47 USER lock project "XXXXXXX" (locked)
"Locked for all users. Project locked for future changes as released."
--09-20T09:56 USER lock baseline "XXXXXXXXX" (locked)
"Locked for all users."
(removed locks)
"ct lslock -all" shows nothing
"rmtype -rmall lbtype:BASELINE_in_progress#\VOB
There are 1228 labels of type "BASELINE_in_progress".
Remove labels? [no] yes
cleartool: Error: Lock (obsolete) on directory element prevents
operation "remove label".
cleartool: Error: Unable to remove label type "BASELINE_in_progress".
The actual error message is
possible stranded temporary lbtype name found: "`abaselinexxx.yyyy_in_progress`".
The idea is to:
remove all the _inprogress types in the vob(s) involved by the UCM components
$ ct rmtype -rmall lbtype:abaselinexxx.yyyy_in_progress#\\avob
There are 1690 labels of type "abaselinexxx.yyyy_in_progress".
Remove labels? [no] yes
promote the baseline into a fully labelled one:
ct chbl -full -nc baseline:abaselinexxx.yyyy#\apvob
The locks which could prevent those operations to complete are:
on the lbtype
on the vob (ie the vob itself could be locked)
on the pvob (the pvob or one of its admin pvob could be locked)
Few remarks, from the comments:
cleartool lslock -all won't display obsolete files ("obsolete" being one form of locking): cleartool lslock -all -obsolete will.
to unlock a set of locked files, you have a choice between for and cleartool find -exec commands.
Windows
for /f "delims==" %x in ('cleartool lslock -all -obsolete -fmt "%Xn\n"') do cleartool unlock "%x"
Unix, in view context...
cleartool lslock -all -obsolete -fmt "%Xn\n" | xargs -i{}
cleartool unlock %x
Note that a cleartool find would unlock everything under a certain path.
If you know that path (and all -- or most of all -- its content) is locked, then it can work:
ct find /path/to/a/locked/directory -exec '/usr/atria/bin/cleartool unlock "$CLEARCASE_PN"'
I want to check in a directory and all the sub-directories into the clear case.
Is there a specific command to achieve it?
Currently I am going into each directory and manually checking in each file.
I would recommend this question:
Now the problem is to checkin everything that has changed.
It is problematic since often not everything has changed, and ClearCase will trigger an error message when trying to check in an identical file. Meaning you will need 2 commands:
ct lsco -r -cvi -fmt "ci -nc \"%n\"\n" | ct
ct lsco -r -cvi -fmt "unco -rm %n\n" | ct
(with 'ct being 'cleartool' : type 'doskey ct=cleartool $*' on Windows to set that alias)
But if by "checkin" you mean:
"enter into source control for the first time"
"updating a large number of files which may have changed on an existing versionned directory"
I would recommend creating a dynamic view and clearfsimport your snapshot tree (with the new files) in the dynamic view.
See this question or this question.
the clearfsimport script is better equipped to import multiple times the same set of files, and automatically:
add new files,
make new version of existing files previously imported (but modified in the source set of files re-imported)
remove files already imported but no longer present in the source set of files.
make a clear log of all operations made during the import process.
:
clearfsimport -preview -rec -nset c:\sourceDir\* m:\MyView\MyVob\MyDestinationDirectory
did you used -recurse option in the clearfsimport command.
Example: clearfsimport -recurse source_dir .
This should help.
If you're using the Windows client, right-click on the parent folder, select Search, leave the file name field empty, click Search, select all the files in the result window (ctrl-A), right-click on them and select ClearCase -> Add to Source Control
If you are in windows you may try,
for /f "usebackq" %i in (`cleartool lsco -cview -me -r -s`) do cleartool ci -nc %i