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"'
Related
But check in/out & merge should happen for the same work_branch.The only aim is that work_branch should not allow applying any label.
Since:
locking the brtype for that branch would also prevent checkout/checkin,
locking the lbtype would prevent any mklabel on any branch,
You can try instead definining a pre-op trigger on mklabel:
If that mklabel operation is done on the wrong branch, that pre-op trigger would exit with a non-zero status, preventing the mklabel to proceed and apply the label.
See EV (Environment Variables) section of the mktrtype command.
See an example (not based on branches) in this thread:
ct mktrtype -element -all -preop mklabel -exec "/path/to/script"
Actually. You can also use a trigger with an inclusion list.
cleartool mktrtype -element -all -preop mklabel -brtype nolabel -exec "ccperl -e \" die();\"" NOLABEL_TRIG
Will block any attempt to make a label on a given brtype. Pardon the windows centric nature of the above.
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 have somehow created a branch of a file in clearcase UCM that is not part of an activity. I have no idea how to reproduce this, but my stream is showing many files with this symptom. How can I find these files, remove them, and prevent it from happening again in the future?
Here is an example of one such file, names redacted to protect the innocent:
xxxxxxxxxxx.cpp##/main/xxx-integration/xxxxxx-xxxxxxxx/0 Rule: .../xxx-xxxxxxx/LATEST
A ct lsact -long | grep <filename> returns no results.
Update:
I used a find command to track down all the files that are on the branch given (and redacted) above, though I still do not understand the issue.
Per VonC's answer, where is what I ended up doing:
cleartool find . -type f -version "version(.../xxx/LATEST)&&version(.../xxx/0)" -print | tee ~/tmp/files2
I then read through the list of files generated to make sure they made sense, then I verified they were not attached to an activity and removed the versions:
cat ~/tmp/files2 | while read
do
if [ -z "$(ct describe -fmt "%[activity]p" $REPLY)" ]
then
ct rmbranch -f ${REPLY%/0}
fi
done
That can happen ig those file were checkout in a base ClearCase view, ie a non-UCM view, withg a simple config spec:
element * .../xxx-integration/LATEST -mkbranch xxxxxx-xxxxxxxx
You can use a find command similar to "How can I find all elements on a branch with version LATEST that has no label applied?".
The difference is: for each version found, you need to describe it in order to check if there is an activity attached to it or not (with a fmt_ccase):
cleartool describe -fmt "%[activity]p" "$CLEARCASE_XPN"
What is the command in Clearcase to delete the branches of an element in which it is not modified (Element's version in that branch is "0") ?
You can simply remove the version 0 of that element (that I detail here).
That will remove the associated branch.
cleartool rmver file##/main/aBranch/0
You would need to "cleartool find" all elements with a version 0 (and no version 1), and rmver those version 0.
For a given branch, this would return all the versions to delete:
cleartool find -type f -version "version(.../blah/LATEST)&&version(.../blah/0)" -print
You can combine that with an exec directive:
# on Windows:
cleartool find ... -exec "cleartool rmver --force \"%CLEARCASE_XPN%\"
# on Unix:
cleartool find ... -exec 'cleartool rmver --force "$CLEARCASE_XPN\"'
Be careful with rmver, this is a destructive operation, so do test that carefully before executing the full find -exec rmver command!
Another approach is mentioned in "Purging Zero-Version-Only Elements in ClearCase" article, by George F. Frazier:
you need to purge your view of those troublesome entities.
Run the following command to find all zero-version elements:
cleartool find -avobs -branch'{
brtype(mybranch)&&!
(version(.../mybranch/1))}'
-print > c:\files.txt
This will find all elements with no version 1 on mybranch (if you read closely you'll notice it doesn't do the right thing if you have removed the 1 version of an element that already has versions greater than or equal to 2 — this is a rare situation though).
Once finished, it's simply a matter of using rmbranch to nuke the elements (make sure you know what you're doing here!).
There are many ways to do that; since I run the MKS toolkit, I execute the following from a command window:
cleartool rmbranch -f 'cat c:\files.txt'
Tamir suggests a trigger to automatically remove version 0, as listed in the IBM Rational ClearCase: The ten best triggers, under the section Empty Branch.
cleartool mktrtype -c "Automatically remove empty branch" -element -all -postop uncheckout -execwin "ccperl \\mw-ddiebolt\triggers\test_empty_branch.bat" REMOVE_EMPTY_BRANCH
That is good for future cases where an undo checkout leaves a version 0.
rmver won't work.
/home/ccadmin $ cleartool rmver -force ./VaREngine/Makefile##/main/nz_mig/nz_relOne/0
cleartool: Error: Cannot delete version zero without deleting branch: "./VaREngine/Makefile".
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.