Why Clearcase mkelem infinitely waits in windows? - clearcase

I am trying to add a file to Clearcase via Cleartool command.
I have executed the following command into my "cmd"
C:\Users\MyUser\Desktop>cleartool mkelem "Z:\MyApplication\Impl\DataModels\Model\Build.Model.ps1"
Creation comments for "Z:\MyApplication\Impl\DataModels\Model\Build.Model.ps1":
It is infinitely waits without doing anything. If i do Ctrl+C it says interrupted.
What am i missing?
Update:
I have tried with cleartool mkelem -c "some useful comment" option also. but still fails. As instructed by #VonC i have even run the same command in Snapshot view but no luck.

Try at least to:
set the comment in the cleartool mkelem call itself:
cleartool mkelem -c "..."
check if the parent folder is checked out.
check if there is a pre or post-op trigger on element creation, as mentioned in this thread.
Maybe the script associated with that trigger has an issue and freezes the all process.

As it looks to be waiting for a comment...
Cleartool, when it prompts for a comment, needs a period on a line by itself to complete the comment prompt. This allows cleartool to acccept multi-line comments.

Related

How to delete a view tag with special characters in ClearCase

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.

ClearCase: how to list the text all the commit messages?

I believe this is a simple question: I want to find which files were modified when I fixed a bug. I know some words in the commit messages. In other version control I'd list all the commit messages and grep for my correction. Something like:
svn log|grep -C 10 'Access Violation'
I can't find in ClearCase how to do the simple task of listing all the commit messages of a stream. I want to see also the commit messages of the child streams. Can someone help me?
That would be because there is no "commit message" per se in ClearCase.
each file can have its own comment when checked-in
the UCM activity in which you are checking in a file has its own comment
the UCM baseline which will include several activities has its own comment.
So, for instance you can list activities (as I illustrate in "how to find the list activities delivered to integration stream on a particular day?"):
cleartool lsact -r -in stream:aStream#\aPVob -fmt "%n %c"|grep "Access Violation"
and grep on their comment message, using the fmt_ccase format to display the associated comment (with %c).
Note the -r (recursive) option, which will include activities from the child streams.

what is the echo command in clearcase?

I have a question about clearcase, someone helped me on some issue in clearcase, he used a command as follow: echo " " > xxx.log and
cleartool co -nc filename
what does this mean?
When you have a file which is "checkedout but removed", as described in ct ls:
The element was checked out in this view, but the view-private file was subsequently removed.
You may have deleted the file.
A solution to restore that file is to checkout it again, but if you do that directly, ClearCase would complain about being unable to access said file (because it isn't physically there anymore).
Hence the:
echo " " > afile
You need to have some content in that file in order to make a cleartool command on it.
So even if its content is a bogus one, it at least allows you to proceed.
Then, you can checkout it again (-nc means without comment, but it also means "takes the previous comments used on the current checked out version)
cleartool checkout -nc afile
Another way to restore it is to uncheckout the file:
cleartool unco afile
That will also restore its content.
The first command writes a space to xxx.log; echo is a shell command and has nothing to do with clearcase. The second command checks out filename without comments. These two commands seem to be pretty unrelated, unless there something else you haven't told us.
Just a tip:
'echo' might to used to clear xxx.log file.
co - stands for check out filename,
nc - stands for no comments
Might be helpful: http://www.yolinux.com/TUTORIALS/ClearcaseCommands.html

Delete file from ClearCase checked out on another branch

I am trying to delete a file in ClearCase. When I attempt to delete it I get a message that the element has checkouts. When I do a version tree on the file I see that the file is checked out by another user, in another view, on a different branch.
How do I delete this file? In addition why doesn't ClearCase let me delete this file?
You can delete it through the command line and cleartool, by forcing its delete (option which isn't available with the GUI)
cleartool rmname -force theFile
Don't forget to checkout the parent directory first, then to checkin that same parent directory, in order for everyone to see that you have dereferenced that file within said directory.
See cleartool rmname:
–f/orce:
Forces the removal of the name when there is at least one checkout of the element.
When used with –nco, suppresses the prompt for confirmation.
That will work even when you had this before:
, as explained in the technote "About cleartool rmname and checkouts".

How do I roll back a file checked in to Clearcase?

I have a file in my Clearcase repository. I checked it out and modified it, and then checked it back in.
I haven't done anything like make a baseline, or rebase, or deliver in my stream/view.
I regret having made the changes to this file--I should have undone the checkout, in retrospect.
How do I roll back the modifications? (Or undo, or revert, or whatever the correct nomenclature is.)
What is described by skwllsp can be be done in a dynamic view through the use of extended pathnames
cd m:/myDynamicView/MyVob/path/to/file
cleartool lsvtree myFile
cleartool checkout -c "cancel co" myFile
copy myFile##/main/xx myFile
cleartool checkin -nc myFile
with xx being the version number you want to restore.
But should you have made multiple checkins, including some you want to cancel, ClearCase allows you to cancel part of the previous checkins through Subtractive Merge
See IBM "to remove contributions of some versions" (and merge man page)
You can remove all changes from a range of versions at once. For example, the following command removes revisions to versions 14 through 16 on the main branch:
On the UNIX system or Linux:
cleartool merge -graphical -to opt.c -delete -version /main/14 /main/16
On the Windows system:
cleartool merge -graphical -to opt.c -delete -version \main\14 \main\16
You can also remove the changes from one version at a time. For example, the following commands remove only the changes in version 14 from the version of opt.c checked out the current view:
On the UNIX system or Linux:
cleartool merge -graphical -to opt.c -delete -version /main/14
On Windows systems:
cleartool merge -graphical -to opt.c -delete -version \main\14
Alternatively, in any of the examples above, you can leave out the -version argument if you use the version extended path for the contributor-version-selector.
Finally, the one thing to not do is a rmver.
This command destroys information irretrievably and this is rarely a good thing.
Clearcase can do much better than just making a new version where you undo the change!
Open the version history on your file, find the version you mistakenly checked in, and destroy it (select version to destroy and find the appropriate command under the Versions menu).
This is what rmver does too, if you want to use the command line.
As VonC said your this destroys your mistake irretrievably. I'm not seeing a downside to that.
Open version history for this file, then open in your editor a proper version of the file from the version tree, check out file once more, replace its with content of the previous correct version and check in. Don't forget to compare the previous version and the last version.
cleartool unco #filename should do the job for you.
But if the version in the main branch/ branch from where your branch is created, goes forward with versions, when you undo your checkout, the new version is acquired instead of the version from which you branched.

Resources