when i execute cleartool mkbl it hangs and never returns. The window has to be killed and restart.
what might be the possible reasons behind it and how do I fix it?
Since UCM cleartool mkbl put a baseline on all modified components, that means that, behind the scene, it will call mklabel.
And that can takes time, if there are a lot of new or modified files to labelled, one by one.
If this isn't the issue, then you need to check the logs (both of the client and the server), in order to see if all the necessary services are in place (like the albd server, the lock manager, ...).
You can use cleartool getlog for that.
Related
I have checked out a file say "a.c" in my activity branch which is having version 3 from main line in clearcase and I did some changes to that file.
Now I want to do check in of that file on the main line but the latest version of that file in main line is now 7.
I want to put my changes to that file and hence it will create the version 8 of that file.
So how can I do check in so that I can merge my changes to the latest version of file. In other words I am having 3rd version of a file and I want to give my changes to the latest version of the file
Even before the delivery, a simple checking should trigger the merge, in an UCM dynamic or snapshot view.
If there is any conflict, the cleartool mergetool will popup then.
That is what this technote details:
To merge the latest version with your checkout
When you first check in (on Windows systems, issue the Check In command for) a non-latest version of an element, one of the following actions occur:
On the UNIX system and Linux, you see a message that the version you checked out is not the latest on the branch, and the checkin is prevented.
Enter a command in the following format:
cleartool merge -graphical -to file-or-directory-in-your-view \
file-or-directory-name##/main/LATEST
Using the -graphical option starts the Diff Merge or, if you merge XML versions, the XML Diff Merge tool.
The argument on -to specifies your checked out element.
The other argument is a version-extended pathname that specifies the latest version on the branch on which you are working (see the pathnames_ccase reference page for a complete description of syntax).
After the merge completes, save the results and check in the version by entering the cleartool checkin command from the view.
On Windows systems, a window opens and asks whether you want to merge the file now. If you choose to merge, an automatic merge is attempted. If your input is needed to complete the merge, the Diff Merge or XML Diff Merge tool starts. After the merge completes, you are prompted to check in the element.
It sounds like you are using a Base ClearCase branch to do your work. You have a few options in that case. You can, and should, check the work in on your private branch and then do your merge operation...
Options include, but aren't limited to:
Use the manual cleartool merge command.
Run "cleartool lsvtree -gra {file}" or use the "version tree" clearcase context menu item to bring up the version tree. Right click on the current version and you will get an option to merge to any other version...
If you're using view profiles and are done using the private branch, there is a "finish private branch" option in the ClearCase home base.
If you checked out unreserved on the same branch as has been updated, you can use the vtree browser or the command prompt to merge your changes forward and check them in.
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.
Every time I try to copy clearcase file from view location to another location, it generates the following error:
The file cannot be opened because it is being used by another process.
Please close all applications that might access this file and try again.
Any ideas why this is happening?
That explains probably your previous question: some process must keep an handle on the files you want to copy.
Try to close as many apps as you can, or even try that copy just after a reboot.
That is not a ClearCase issue. Its totally Windows one. You need not to close all apps to find the lock. try to install the "unlocker" application it will notify you what is locking your process
http://download.cnet.com/Unlocker
Enjoy,
Eli
Once you label file versions in a release, ideally you want to protect that code from inadvertant removal (please read everything before commenting). It is too easy to delete the code.
I know I can lock the label but the file versions attached to the label don't get automatically locked (you would have to create a perl script to do that?). You can lock an element but not an element version. Furthermore, once you lock an element, you can't check it out!!!!! STUPID. This stops future development! All I want to do is protect the code I developed (without copying it elsewhere for archive). A repository should protect the code you develop.
Of course, there is the protect command but that doesn't work in snapshot / web views.
Again, ideally you would want to lock all the element-versions in a release but still be able to continue development. The lack of this feature seems to be a gross oversight.
Any ideas? (if you have any perl scripts, please post)
It is too easy to delete the code.
It shouldn't be: the only way you will be removing that labelled version from a ClearCase VOB is through destructive commands like cleartool rmelem or cleartool rmver.
All you need to do is to have a (preop) trigger in place denying those commands for everybody (except a ClearCase admin).
Something along the lines of:
cleartool mktrtype -nc -all -ele -pre rmelem -nusers $nusers -exec \"$perl_cmd -e exit(1)\" NO_RMELEM\aim"
I would still recommend to lock the label anyway, in order to make sure it isn't moved to another version.
As in:
ct lock -nusers vobadm lbtype:FOO_LABEL#vob:/vobs/admin
But again, if rmver is denied, your (labelled) code is safe.
Actually, the OP was talking about rmname (the DEL) in ClearCase Explorer.
The fear is that if a file is deleted, and a label is moved, then one could ignore for a long time the deletion.
BUT a label should never be moved:
the label from a ClearCase UCM baseline is immutable (you cannot move it)
a label in base ClearCase should always be locked
Here is the situation,
I have installed and configured ClearCase Multisite,I did a mkreplica from SITEA (/dev) to SITEB (/dev). My import went successfully on SITEB. I happen to do few syncreplicas too on Both( SITEA and SITEB). I had both configured on Win2003.
Now the SITEB Operation system Win2003 happen with some OS related issues. Now I had recreate an Instance of win2003 and configured CC Multisite on it. Now since everything had been wiped out: I tried to do an mkreplica from SITEA /dev to SITEB /dev (A win2003 new instance)
But, to my surprise, it says SITEA has already exported a packed and exits.
I wanted to know if there is a way to wipe out old history of SITEA for /dev or do I have to rename SITEB to something different? I haven't tried renaming but before I do just need some views over it.
Amit
I no longer work in a clearcase environment, so this is from memory, but in order to get an exact overview of what is exported or not run the
multitool lsepoch
command and then try to figure out which epoch numbers that are not up to date (as far as I remember you can request numbers from the remote side with the -actual option). If you want SITEA to re-export some things it thinks it already is finished exporting, you have to change the epoch number for the replica you want to import into.
When you consider the mkreplica man page, it could be as simple as the destination directory (the directory for use by mkreplica as a temporary workspace) already existing.
You also have this technote which reports why the error, multitool: Error: Unable to create directory ".../VOB.vbs/s": File exists, occurs when attempting to import an IBM® Rational® ClearCase MultiSite® replica creation packet using multitool mkreplica -import.
It involves unregistering (unregister+rmtag) the vob created by the first mkreplica.
if you are 100% certain that SITEA is most up to date, and the old SITEB is no longer needed. You can do this...
At SITEA
cleartool chmaster -all -obsolete_replica replica:SITEB replica:SITEA
cleartool rmreplica replica:SITEB
Once the above is done, you are free to re-create SITEB from SITEA as per your usual practice.