Given a file system path such as "D:\pkirkham_view\VOB\Folder" or "U:\VOB\Folder\", is there a mechanism to get the path which would work in the config-spec to to load that folder "/VOB/Folder/" ?
Either CAL or cleartool commands would be fine. This is to run on client machines with ClearCase LT installed.
(I haven't found anything usable in CCElement.get_PathInView() or the various cleartool ls commands I've tried)
There is no native command, but the only load rule you need is based on a vob name.
So you need a script able to:
1/ remove everything including the name of the view
(which you can obtain with a '<aPathTo>\VOB\Folder\;cleartool cleartool lsview -s -cview)
D:\pkirkham_view\VOB\Folder => \VOB\Folder
U:\VOB\Folder\ => \VOB\Folder
2/ Build your load rule accordingly:
load \VOB\Folder
3/ Append that load rule to your config spec (if you are already within the view):
cleartool catcs > aConfisgpec.txt
echo "load \VOB\Folder" >> aConfisgpec.txt
cleartool setcs aConfisgpec.txt
The OP comments:
So, if I create a snapshot view whose tag name is 'pkirkham_testing_view' on path 'D:\thursday', how is that a substring extract?
That is a good point, since one can name the root directory with any name.
I would recommend naming that directory with the tag of the view.
But that is not the case, you need to determine the root directory of a snapshot view:
start in 'D:\whatever\path\VOB\Folder',
try a cleartool lsview -cview:
if it respond correctly, cd .., and repeat 2.
When it exit with an error, remove the substring of that directory from the initial path. What remains will be your load rule.
Related
Background
I currently am testing a script that creates a temporary view and checks out four package files to be updated by a process. However, my script hasn't gotten to the point where it can reach the uncheckout step. This results in 30+ temporary views that all contain a checkedout version of the package files.
Attempted solution
I could go in to the graphical clearcase tree and manually ctrl-click all the temp views that are checked out, then click on the uncheckout button. However, this will get unweildy after a few hundred tests, so I want to know of a command line way to do this. All of my temporary views are formatted with "TMP_abc_QUA_###".
Question
How can I uncheckout a file across all temporary views from linux command line with bash?
As described in "How to remove checked-out references of a view from a VOB", you can simply describe a vob:
cleartool describe -long vob:\baseccvob
You will see which views are holding objects:
VOB holds objects from the following views:
MYHOST:C:\VIEW\TEST.vws [uuid a7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4]
For each views which are part of your temporary views, you can do:
cd /aview/aVob
cleartool rmview -uuid fa7fc590.42f34d53.ae68.b6:30:f5:30:c5:a4
That will remove any checkout status for any file in aVob for that view.
Loop and repeat for other temp views.
I used in the past (Windows syntax)
cd M:\aview\avob
ct descr -l vob:\aVob|grep TMP_|gawk "{gsub(/]/,\"\",$3); print \"cleartool rmview -uuid \"$3}"|cmd
On Linux:
cd /views/aView/vobs/aVob
cleartool descr -l vob:/vobs/aVob|grep TMP_|gawk "{gsub(/]/,\"\",$3); print \"cleartool rmview -uuid \"$3}"|sh
I am new to IBM ClearCase.
I have a dynamic view with named "current_view". I am able to set it to the default config spec with the below command.
cleartool setcs -tag current_view -default .
But now I am trying to set it into specific track.
So how should I give the argument in place of "-default", so that config spec will get changed from default to specific configspec?
And one more info I want to know , when I am setting config spec to any specific track from which location and which file "setcs" command is reading
the track information.
One option is simply to edit the config spec with cleartool edcs:
cd /view/myView
# or
cd M:\myView
cleartool edcs
Edit the config spec, and add your branch you want to follow
element * CHECKEDOUT
element * .../yourBranch/LATEST <=== Add this line
element * /main/LATEST
Save and close: the dynamic view content will automatically adjust to your new selection rules.
You could also edit your condif spec in a file, and use that file as an argument of cleartool setcs
cd /view/myView
# or
cd M:\myView
cleartool setcs afile
That way, you can script the all process (no interactive step)
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 am trying to automate updating my clearcase view and build the code in a bat file. I want to run the update command and then check the log to verify its success. For this I want to save the update log in a specified location rather than its default location
Now, cleartool allows you to specify your own log file within the cleartool console
cleartool>update -log pname
but when i use the same as a single command, it doesnt work
D:> cleartool -log pname --------- THIS DOESNT WORK
any ideas?
Thanks
RB
you need to do (from cleartool update man page):
cleartool update -log pname /path/to/root/view/directory
A cleartool update outside a view won't work.
A cleartool update with the path of a root view directory will work.
If you specify that root directory, then you can execute the cleartool update command from any path, including D:\.
pname ...
If you do not specify –add_loadrules, this argument specifies the files and directories to update.
All specified directories, including the root directory of the snapshot view, are updated recursively.
For some reason some users produced some files that end in "##" (...) (I think because they have in the CCRC the gui option to show the version extended pathname and i think that has somewhere a little bug).
Now... they are unable to remove or rename these files (it returns "not a object in the vob")
how can they rename or remove these files?
update
Resolved I forgot to use the complete rmname "a.doc####\bla\1", after the full path i could delete them.
The simplest solution would be to try to list and remove those objects from a base ClearCase view directly on the CCRC server (or any base ClearCase client).
From this kind of ClearCase installation (CCRC server or full ClearCase client), you do have access to cleartool (the ClearCase CLI -- Command Line Interface --), and you can:
cleartool ls: list the files in the view, to check those files with ## are indeed there
cleartool rmane -force to remove them
The OP used
cleartool rmname "a.doc####\bla\1"
, meaning he had to use the extended path (file name + ## + version path) of the file ended with ##, hence the four #: file####version.