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".
Related
I have a question regarding ClearCase. From the documentation of the mkelem command I read:
The mkelem command creates one or more new elements. By default, a new element can be created in a directory only if that directory element is checked out. mkelem appends an appropriate line to the directory's checkout comment.
Why is this the case? And, as it says by default, how do I change this default option? I couldn't find anything about this in the doc.
It is the case because the element to be created needs to be registered in the list of elements maintained by the parent folder.
Since that list is about to change (because you are adding a new element), the parent folder needs to be checked out in order for its list to evolve.
Then a check in will record that changes (if you undo checkout the parent folder, then the element added to source control would end up in the vob/lost+found folder, as it wouldn't be referenced by any directory version)
Note that if you have many element to add to source control (many mkelem to make, meaning potentially many parent folders to check out), you can still use clearfsimport instead, as I explain in "how to run mkelem command in command prompt" or "How to add a directory tree to a ClearCase repository?"
Let's say there is a file called myfile.java. I checked it out and I was working on it. Before checking it in, I have lost my hard drive and I had to get a new hard drive.
Next time that I want to check out the file, it says that I can not check out. It was already checked out in the old view which has gone. I have to mention that I am using the option "re-use development stream option".
Is there anything I can do to be able to checkout the file once again?
You can completely unregister your old view in the vob of that file: that will remove the "checkout" status associated to that file.
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
To find the uuid of your old view, try a:
cleartool descr -l vob:\myVob
And look for a view storage path including your old view name in it.
I created this new clearcase element and checked out but when I try to check in, it is giving an error saying "no such file or directory". I can see this file checked out in an activity so how can I get this file check in?
Thanks.
The easiest way to debug this is through a shell
cd /path/to/parent/directory/of/the/file
cleartool ls
Look for the version and selection rule for that file.
Check also the config spec of your view
cleartool catcs
# or
cleartool edcs
See if the config spec does start with a:
element * CHECKEDOUT
For a "checked out but removed" status, you can refer to "How to recover a file from “Checkout but removed” state?".
The idea is to "undo checkout" a dummy file (same name, but empty), in order to recover it as before any local change.
There is no easy way to recover the local changes done while that file was ched out and present (except for some file recovery tool like Recuva, but it is a long shot).
How can I use cleartool rmname to remove a file, that is checkedout by some one else, from a folder? Is this possible?
The command-line cleartool rname -force is only necessary when the file is checked out in another branch.
That allows to bypass the error message: 'file' has checkouts
In that case, you need to check out the parent directory first, rmname, and then don't forget to check in the parent directory, or your file will still be visible by others.
See more at the technote "About cleartool rmname and checkouts"
There is a -force option available for cleartool rmname from command line that will allow the command execution to work even while there are checkouts.
This option forces the removal of the name from the directory when there is at least one checkout of the element, but it does not actually cancel any checkouts of the element.
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.