I'm sure I was able to pop up the ClearCase Activity Properties window from the command line at one point.
Does anybody how to make this happen?
Thanks!
This might be one of the executable in <IBM/Rational/ClearCase>/bin, but you can also try (using cleartool describe):
cleartool descr -graph activity:myActivity#\myPVob
Otherwise clearprojexp.exe launched the UCM project manager itself.
Related
I have to use ClearCase at work and the basic workflow requires me to do something like:
cleartool setview <view-tag-name>
view-tag-name is a dynamic view I might add. From what I've gathered this opens up a new shell that allows me to access files in /vobs/some/path that go through a mounted MVFS file system. However this second shell on top of the existing shell breaks my Emacs client - Emacs daemon cooperation. Moreover, in another SO answer someone was saying that he didn't bother with setview at all and so instead of accessing:
/vobs/some/path (from within a setview shell)
… he would access:
/view/view-tag-name/vobs/some/path (without using a setview shell)
I've experimented a little and it seems that all cleartool commands work the same way whether I am in /vobs/some/path (in a setview shell) or whether I am in /view/view-tag-name/vobs/some/path (in a plain shell).
So my questions are:
what's the difference between working in /vobs/some/path in a setview shell versus working in /view/view-tag-name/vobs/some/path in a plain shell?
what is the proper term to use when referring to the /view/view-tag-name directory?
why when I do ct lsview -l -properties -ful view-tag-name I don't see any reference to the /view/view-tag-name directory? Isn't this directory associated with the view?
what's the difference between working in /vobs/some/path in a setview shell versus working in /view/view-tag-name/vobs/some/path in a plain shell?
Do not use cleartool setview: As I explained before, the cleartool setview command opens a subshell in which commands are supposed to be run, which can be problematic.
Working in /view/view-tag-name/vobs/some/path means you remain in your main shell, with all its properties.
what is the proper term to use when referring to the /view/view-tag-name directory?
That references the full path view root folder (inside which you are mounting vobs and accessing versions based on the view config spec and its selection rules)
In /vobs/some/path, you can still see the view you are in with cleartool pwv ("path working view").
why when I do ct lsview -l -properties -ful view-tag-name I don't see any reference to the /view/view-tag-name directory?
You are seeing the property of the view, which will then be mounted in /view/view-tag-name (on Unix) or M:\view-tag-name on Windows.
Those properties make no assumption on the runtime usage of that view, they only display static metadata (like the view storage or the view type)
If your workflow was to start emacs and then set into a view from there, things will be strange indeed.
The only thing that setview does differently from startview is that it starts that chrooted shell. Only that shell, and its descendants, will see source code in /vobs/vobtag/... If you work in multiple "setview" shells (for multiple versions of your app to maintain, multiple phases, etc.), you would have multiple otherwise identical shells accessing different versions of the same files via apparently-identical paths.
One thing to be aware of when working with ClearCase is that directories are versioned too. As a result, files added in one view may not appear in the other view if:
They are based on different versions of the parent directory; or
The parent directory of the file added to source control hasn't been checked in yet.
Unless your build process requires VOB contents to be visible at /vobs/vobtag, I'd concur with #VonC about not using setview.
I can't really add anything to VonC's other comments.
I am having a folder where lot of files and subfolders , adding it to source control via UI is consuming much time.
How to add all the files (including files inside subfolder) to source control using cleartool?
(I am using clearcase UCM)
As mentioned in "How can I use ClearCase to “add to source control …” recursively?", clearfsimport is the way to go.
However, clearfsimport will take a source an import it in your view, so:
it is best to keep the source outside your view (to avoid confusion when ClearCase tries to add the source file in the destination which is the same directory)
you must "clean out" the source directories first (because the clearfsimport command will import... all the files under the root directory you mention)
See "Creating a new subdirectory structure in ClearCase?" as an example: you can preview the result of an import first.
Please user clearfsimport or if you are working with eclipse or Intellij then there are plugins from sourceforge (eclipse) which has a options to share entire project at once to CLearcase , Below are the plugin details.
https://sourceforge.net/projects/eclipse-ccase/
Note : Clearcase has a limitation that if there is a text file with more than 8000 characters in single line , There is error at run time using clearfimport utility, This can be solved by writing your own bash script to do recursive checkin by handling the exception case . Hope it helps .
I saw another comment from a similar clearcase question that suggested typing in '*' in the topmost directory required, select all, rc->cc->add to source control.
I am working in a dynamic view in Unix platform. I need to hijack a file temporarily and cancel the hijacking later. But the command chmod +w filename is not working.
I get the message chmod: WARNING: can't change filename.
I can change the read-only attribute of the file from a snapshot view in windows.
Questions:
Is hijacking possible in a dynamic view? If yes, how?
Is there a cleartool command to cancel hijacking of a file?
One of the side-effects of a dynamic view is that ClearCase will control the attributes of the file you access to through the network, as opposed of a snapshot view (where everything is copied on your hard drive).
1/ Yes it is possible, even though it isn't really an "hijacked" state.
The dynamic equivalent is named "eclipsed": the idea is for a private file of the same name than a versioned one to take the place ("eclipsing") of the versioned file.
You simply make a copy of that file as a backup, and make that file invisible by not selecting it (type "cleartool edcs" anywhere within the dynamic view):
element /vob/path/to/file -none
Then you rename the backup copy, restoring its original name.
2/ to undo an eclipsed file, you simply move it or delete it.
The versionned file (eclipsed by the private one) is restored instantly.
See IBM article "About eclipsed files and ClearCase" for more.
Why not doing an unreserved checkout?
cleartool checkout -unreserved filename
I want to checkout some files from a batch script, but since we use UCM checking out files needs to be associated with an activity. Is there an easy way to show the GUI for creating/selecting an activity to associate the checkout with?
You can pop up the dialogue by using the cleardlg program with arguments /checkout .
You can simply ask for an activity name in your script, and then use the cleartool setactivity command
cleartool sectact -view viewTag -none # make sure to unset any previous activity
cleartool sectact -view viewTag newActivity # set the new activity (name#\pvob)
You can launch the ClearCase Project Explorer (UCM GUI) with clearprojexp, but I don't think a "UCM activity dialog box" is available as a separate executable.
Why do I get these .MKELEM files? How do I get rid of them?
I found some docs that said they are temp files created by ClearCase GUI when adding files to source control. But sometimes, they don't go away.
ADDITIONAL INFORMATION: I "get access denied" trying to delete or rename the .MKELEM. They seem to get created when I add new files to clearcase.
As mentioned in the mkelem tip page:
During the element-creation process, the view-private file is renamed to prevent a name collision that would affect other Rational® ClearCase® tools (for example, triggers on the mkelem operation). If this renaming fails, you see a warning message.
If a new element is checked out, mkelem temporarily renames the view-private file, using a .mkelem (or possibly, .mkelem.n) suffix. After the new element is created and checked out, mkelem restores the original name. This action produces the intended effect: the data formerly in a view-private file is now accessible through an element with the same name.
If mkelem does not complete correctly, your view-private file may be left under the .mkelem file name
The fact that a .mkelem stays can be, like LeopardSkinPillBoxHat mentions in his answer, because of a file blocked due to a process.
It can also happens:
in ClearCase view incorrectly protected (where ClearCase can checkout the new element, creating a version 0, but cannot check that element in.
alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.dev.doc/topics/cc_dev/images/creating_element.gif
when a trigger prevents the checkin part of the new element creation
when the view actually exclude CHECKEDOUT versions! (no 'element * CHECKEDOUT' rule...)
on Solaris 10, due to an incorrect format in one of the ClearCase jvm config file. (ClearCase 7.1)
when add to source control is used on Windows in views mapped to a mount point (Mount points are persistent directories that point to disk volumes), only in old ClearCase 2002 or 2003.
See also the Under the hood: What happens when you add to source control article.
The .mkelem files are temporary files generated by ClearCase when adding a file to source control. If the file gets added succesfully, they are usually deleted. If something goes wrong during the process (e.g. it cannot create the branch specified in your config spec), the .mkelem file may be left behind.
I'm guessing that a process or service somewhere has a lock on the file. Rebooting should fix the problem. Or try using something like Process Explorer to see what may have locked the file.
Also, from this page:
.mkelem
Files being added to source control
from the GUI will use this extension
during an "Add to Source Control"
operation.
If you see this file in your view
during the mkelem process, that is OK.
If you still see the file after the
mkelem operation is complete, that is
not ok. You will likely need to rename
the file (remove the .mkelem
extension) and add it to source
control again. This can be seen when
your antivirus software is scanning
the mvfs. Refer to technote 1149511
Support Policy for Anti-Virus and
ClearCase for further information.
You may try the following from command prompt:
ct ls -l {filename}.mkelem
This will show the links,
then please try the following to link the actual file:
ct ln -c "scm:relink" {link} {actual filename}