I have to move the trigger's scripts from one server to another, on both linux and windows.
As far as i know i have to use the ct mktrtype command with the -replace parameter, I've read on IBM web site that i have to use the same command that was used to create those triggers.
How can i identify the command that was used.
Here is part of my triggers:
trigger type "REMOVE_EMPTY_BRANCH"
2007-11-27T15:29:00+02:00 by vobadm.ccusers#tlv-vob2
"Automatically remove empty branches"
owner: ARRS\vobadm
group: ARRS\ccusers
all element trigger
post-operation rmbranch, rmver, uncheckout
action: -execunix /usr/bin/perl -I /tlv-vob2/triggers/lib /tlv-vob2/triggers/rm_empty_branch.pl
action: -execwin \\tlv-vob2\perl\bin\perl -I \\tlv-vob2\perl\lib -I \\tlv-vob2\triggers\lib \\tlv-vob2\triggers\rm_empty
_branch.pl
trigger type "RESTRICT_BASELINE_OPS"
2007-11-28T13:20:20+02:00 by vobadm.ccusers#tlv-vob2
"Restrict normal users from creating baselines, unless they are performing a rebase or deliver"
owner: ARRS\vobadm
group: ARRS\ccusers
all UCM object trigger
pre-operation mkbl, chbl, rmbl
action: -execunix /usr/bin/perl -I /tlv-vob2/triggers/lib /tlv-vob2/triggers/mkbl_pre.pl
action: -execwin \\tlv-vob2\perl\bin\perl -I \\tlv-vob2\perl\lib -I \\tlv-vob2\triggers\lib \\tlv-vob2\triggers\mkbl_pre
.pl
excluded users: vobadm,amason,builder
trigger type "UNCO_POST"
2007-11-27T15:29:00+02:00 by vobadm.ccusers#tlv-vob2
"Safely remove empty branches on uncheckout"
owner: ARRS\vobadm
group: ARRS\ccusers
all element trigger
post-operation uncheckout
action: -execunix /usr/bin/perl -I /tlv-vob2/triggers/lib /tlv-vob2/triggers/unco_post.pl
action: -execwin \\tlv-vob2\perl\bin\perl -I \\tlv-vob2\perl\lib -I \\tlv-vob2\triggers\lib \\tlv-vob2\triggers\unco_pos
t.pl
I need to move the triggers to this path:
Windows: \poseidon01\clearcase\triggers, \poseidon01\clearcase\perl
UNIX: //tlv-vob3/triggers ///usr/bin/perl
It should be something (from cleartool mktrtype man page and this older example)
cleartool mktrtype -replace -element -all -postop rmbranch,rmver,uncheckout -execwin <windows_path> -execunix <unix_path> "REMOVE_EMPTY_BRANCH"
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.
I have a new branch in which I would like to remove some files. I was able to remove some files with this commands:
cleartool co -nc .
cleartool rmname <filename>
cleartool ci -nc .
But for some other files I get this error:
$ ct rmname file
cleartool: Error: Element "file" has checkouts.
In my branch, in my view, these files are not checked out. However I can find some checkout with ct lsco file in other branches.
Why do I get an error. Removing a file from my branch shouldn't affect the other branches, right?
Can I force the command with -f ?
You could try the -force option for the cleartool rmname command, to get past the fact there are other versions checked out. But that -force option might not be available (depending on the cleartool version)
I have seen that option in "Cleartool removing a checkedout file from a folder with rmname" for rmname.
If rmname -f works, then it is the way to proceed.
That error message is more about warning the users that, while the file won't be visible anymore, it is still being modified elsewhere.
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".
I have applied a label to directory in clear case recursively. How can I remove all those labels?
The simplest approach would be in command line, using cleartool rmlabel
cleartool rmlabel -rec YOUR_LABEL yourDirectory
Note: this is for ClearCase V7.1+ only, not CC7.0.x or CCV6.x, and not for CCRC (ClearCase Remote Client)
With older ClearCase versions, you had to do (see technote swg21126736):
# Unix syntax
cleartool find yourDirectory -version "lbtype(YOUR_LABEL)" -exec 'cleartool rmlabel YOUR_LABEL"$CLEARCASE_XPN"'
# Windows syntax
cleartool find yourDirectory -version "lbtype(YOUR_LABEL)" -exec "cleartool rmlabel YOUR_LABEL\"%CLEARCASE_XPN%\""
Note: you could remove a label using a GUI, but as described in technote swg21146450, this is a file-by-file operation only!
(Not very practical if you have hundreds of elements -- files and directories -- to process...)
I could not find the proper command to apply a label to files which are in my current view. I have tried the following command:
cleartool mklabel -r TEST_LABEL /vob/test/a
However, the problem is that this command will apply the "Test_Label" label to every files in the "vob/test/a" directories regardless of whether the files are in my current view.
Is there any command to apply label only to the files listed in my current view?
cleartool mklabel -r(ecurse) LABEL_NAME <directory name>
This command will apply LABEL_NAME to all files in folder and below of your view, you can just go to that directory,then type following command to create and apply label
> cd /vob/test/a
> cleartool mklbtype –nc TEST_LABEL
> cleartool mklabel -r TEST_LABEL .
The mklabel documentation state states, as to what version is labeled:
Processes the entire subtree of each pname that is a directory element (including pname itself). VOB symbolic links are not traversed during the recursive descent into the subtree.
One example mentions:
Attach that label to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory.
Now, if you want to be really sure of the versions actually labelled, one solution is to use a find command, combined with your mklabel:
cleartool find . -cview -exec "cleartool mklabel TEST_LABEL \"%CLEARCASE_XPN%\""
If you had already that label applied to incorrect version and want to move it:
cleartool find . -cview -exec "cleartool mklabel -replace TEST_LABEL \"%CLEARCASE_XPN%\""
That way, you can first list the versions involved:
cleartool find . -cview -print
And then, if you agree with the output, apply the mklabel through the -exec directive.
The OP user1096966 reports making it work with a cleartool ls, to be sure to select only element visible in the current view:
cleartool ls -r -vis
The is no '-exec' directive, so a pipe might be involved, as in (not tested, but you get the idea):
cleartool ls -r -vis -s -nxn | xargs cleartool mklabel -replace TEST_LABEL
The doco is really clear about what is being labelled, in fact the first example shown in doco states that exactly...current view objects are labelled by default & currently selected versions (i.e. if in your view then label it, else not.)
....extract below from doco below (note: context and command and that label-type-selector pname is the last parameter...left blank below because resident in working dir)...
Example:
•Create a label type named REL6. Attach that label to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory.
cmd-context> mklbtype –nc REL6
Regards
Jim2