For some reason, our company don't support clearcase anymore.So I need to remove it from scripts,use folder to replace it.
For the command
Cleartool setview -exec "$RUN_SCRIPT paramter1 paramter2" $MY_CC_VIEW
$RUN_SCRIPT=/vobs/sw/ecomps/tools/script_remote.sh (a script located in view path)
how to replace it?
cd a path that script located in ,then execute the command?
cd $MY_CC_VIEW_PATH/vobs/sw/ecomps && tools/script_remote.sh paramter1 paramter2
cleartool setview is for setting the view content of dynamic views, so if ClearCase is not running anymore, you would not be able to access any dynamic view anyway.
As I mentioned in "Python and ClearCase setview", never use setview in a script anyway: always use the full /view/viewTag/vobs/aVobTag/... path.
But again, if ClearCase is stopped, that dynamic view path would not be accessible: you should at least checkout snapshot views, whose content would remain accessible even if there is no ClearCase server running.
Related
How to Copy the directory and its contents from local file system to VOB (Source control)
I know there are commands (mkdir, mkelem) to create directory , elements and copy the files one by one.
But I would like to know is there any easy way to do this as there are thousands of sub directories and files inside parent directory?
Yes: you can use clearfsimport, which is made precisely for that.
It will do the mkdir, and cleartool mkelem (or cleartool checkout if you import new versions on top of existing versioned elements)
See also "How can I use ClearCase to “add to source control …” recursively?":
clearfsimport -preview -rec -nset c:\sourceDir\* m:\MyView\MyVob\MyDestinationDirectory
About the clearfsimport options used here, see "Creating a new subdirectory structure in ClearCase?".
I am using Cleartool in a build script to update a dynamic view's config spec. The script is a perl script being run on Cygwin. The Cleartool command successfully changes the config spec of the dynamic view, but it does not update the view itself. In the script we use the following commands:
cleartool setcs -tag <view_name> <config_spec_file1>
cleartool catcs -tag <view_name>
The catcs command outputs the expected config spec, and opening up the view's config spec in ClearCase Explorer shows the expected config spec. It is not until we open up the config spec, and simply hit apply, that we see the expected view files (we don't change anything in the config spec, we just open, apply, and close).
We have also tried forcing the view to stop/start after the setcs command, but that didn't work either.
I would expect that the setcs command alone would be enough, as the documentation says that's all that is needed.
setcs documentation
If possible, avoid Cygwin, and run the perl script in a simple CMD session.
You have some resources for getting Unix commands without having to use Cygwin.
Gnu On Windows includes 100+ Unix commands,
Git for Windows has more than 200 of them, plus a msys2 modern bash shell.
If you really have to use Cygwin, add at least a cleartool ls (done in the vob of the view whose config spec just was updated).
An ls should force the files to be updated.
In the ClearCase Remote Client is it possible to find a list of all hijacked files in a given view?
Right-click on your view and select Show Pending Changes. All of your hijacked files will be displayed at the top of the list under the heading Hijacked Resources.
It's also possible through the UI, albeit indirectly.
If you run "Refresh > Update from Repository..." off the context menu, the UI will present you with a list of files it did not update upon completion. This will include all hijacked files.
If you're looking to check out the hijacked files, you can select them all and check them out from that display.
In a snapshot view, it is possible to do so using 'cleartool ls -recurse | grep hijacked' (Unix/Linux) or 'cleartool ls -recurse | findstr "hijacked"' (for Windows)
See the link Identifying hijacked files in a snapshot view
In a Web view or CCRC view, I would think that you should be able to do the same if you have installed rcleartool.
The command "rcleartool ls -recurse | grep hijacked" should work the same way.
Note: Depending on the version of CC on your server, rcleartool you need to use is either a separate zip or either included in the CCRC rich client. It is not included by default in the CCRC plugin for eclipse.
Detecting hijacked files in a web or CCRC view can be tricky, depending on the state of the view itself.
For instance, the .COPYAREA.DB file, if missing or corrupt, means that all or some of the loaded files will appear to be hijacked. (see "About the .copyarea.dat and .copyarea.db files")
Other bugs (swg1PK64597, swg21433085) can affect the list of hijacked files as well, depending on your ClearCase version and your OS.
Another way to list hijacked files it to look for "skipped object" after an rcleartool update:
rcleartool update -noverwrite
(with -nov/erwrite leaving all hijacked files in the view with their current modifications)
Hijacking an element in a snapshot view involves making it writable and making a change to it. There is no lshijack or lsprivate -hijacked command to list the files. While the cleartool update operation does generate a log identifying hijacked files, the best way is to use cleartool ls command which identifies hijacked versions in much less time than an update would take.
Use cleartool ls from the command line and look for the [hijacked] tag on objects.
Example output:
%> cleartool ls
archive.ppt##\main\1 [hijacked] Rule: \main\LATEST
project.doc##\main\1 Rule: \main\LATEST
doc_resources.ppt##\main\2 [hijacked] Rule: \main\LATEST
To obtain a list of all hijacked files in a snapshot view, use the following command:
On UNIX® and Linux® you can run the following command from a snapshot view:
cleartool ls -recurse | grep "hijacked"
On Microsoft® Windows® you can run the following command from a snapshot view:
cleartool ls -recurse | findstr "hijacked"
This command will perform a recursive "cleartool ls" and then use "grep" or
"findstr"command respectively to filter any lines that have the [hijacked] line associated with them.
Note: GREP is a native UNIX command; however, it can be run on Windows if the utility is installed. The grep tool comes with applications like GNU, Free Software Foundation or Cygwin
How can I obtain the list of changed files, given that I have an activity name (and also a project and stream name)?
This is what I tried:
cleartool lsact -l someActivity
But it returns:
cleartool: Error: Unable to determine VOB for pathname ".".
I suppose I should be in the correct view in order to get the contents. Is it also possible to retrieve all content without being in a view?
I obtained someActivity with an cleartool lsproj, then an cleartool lsstream -s -in someProject and then cleartool lsact -in someStream. I can do all these cleartool invocations without being in a view, so I'd like to obtain the changeset.
I'm found this question but the answer only works when in a view. For the record, I'm not confusing the ID with the headline.
You would at least need to add the pvob in which that activity was created:
cleartool lsact -l someActivity#/vobs/aPVob # Unix
cleartool lsact -l someActivity#\aPVob # Windows
cleartool lsact can use the current view if you don't specify any pvob:
If you specify a simple name and the current directory is not a project VOB, this command assumes that the activity resides in the project VOB associated with the stream attached to the current view.
If the current directory is a project VOB, that project VOB is the context for identifying the activity.
lsact would also need a view if you want ClearCase to resolve the path of each version (resolved using the current view path).
Otherwise it would list extended pathnames for each version.
On Unix in a dynamic view, I run the following to find checked out files:
cleartool lsco -s -cview -me -avobs
In a windows snapshot view, this use of -avobs doesn't appear to work. On a vob by vob basis I can run:
cleartool lsco -s -cview -me -all
which returns the checked out names to me for that vob.
Is there a way to tell what vobs have checkouts in a Windows snapshot view? (not sure if Windows vs. Unix is a factor here). I'd like to script the lsco, executing it in each of the vobs in question.
Considering each vobs is a direct child directory of the root directory of your snapshot view, all you need to do is to:
list every direct child directory (whose name represents a vob)
execute your cleartool lsco within each of those directories.
This is consistent with the issue around the usage of "-cview -avobs" mention in this technote:
Local fix
Do not use lsco -cview -avobs.
You needs to run cleartool lsco while cd'd in each Unix vob in the Windows snapshot view.