I have two streams
Int
|--> Dev
I want to make sure Dev has everything similar to Int stream word to word.
I have already rebased Dev stream from Int stream, but I know its not going to make it exact replica of Int.
I know I should be using "clearfsimport" command but I could not understand whats the syntax for it.
Please help me with the command using below assumptions, I am on solaris and will be using cleartool command line interface
project vob directory - /vobs/HowDoI
Stream name -> HowdoI_Int
Int View name -> HowDoI_int_View
Dev Stream name -> HowDoI_Dev
Dev View name -> HowDoI_Dev
See "How can I use ClearCase to “add to source control …” recursively?" for an example of clearfsimport syntax.
In your case, assuming both views are started, and the vob is mounted:
clearfsimport -preview -rec -rmname -nset /view/HowDoI_int_View/vobs/HowDoI /view/HowDoI_dev_View/vobs/HowDoI
Remove the -preview when you think the command does what you think it should.
Note the -rmname option in order to get a mirror image from Int to Dev:
Any element present in Dev which are not present in Int will be rmname from Dev, leaving it exactly as Int (meaning without extra elements)
Error: Must be set to an activity in a UCM view.
That means you must set an activity first in the destination view (the one in which you are importing files):
cd /view/HowDoI_dev_View/vobs/HowDoI
cleartool mkact import_deom_int
Related
Presently I follow this process:
Right click the root of the project and click on Find Modified Files.
Then in the ClearCase Snapshot View Update window, the modified (hijacked) files are shown.
By right click on the file name and click on Compare with Old Version, difference between local hijacked file and the server copy are displayed.
However, the above approach takes very long time (as step 1 itself takes 10 minutes). If I already know the hijacked file path, then is there a faster way to do the same?
This 2007 thread summarizes the options you have; the command line with cleartool 9.0.1.3 also offers a diff, even though the thread claims that it doesn't. See bottom of the post.
convert the hijack to checked out (then you can diff)
OR
rename the hijacked file to something else (like filename.hijacked), reload filename (cleartool update filname) update the file, then run cleartool diff filename filename.hijacked.
OR
run the diff against the dynamic view version (from command-prompt, cd to the hijacked file location, then do the cleartool diff filename M:\view\VOB\path\to\file)
I used to do the third option, as it does not require to touch the hijacked file.
With cleartool, compare an extended path name specifying a version, e.g. /main/LATEST, to an simple path. (A command line can be opened conveniently from the context menu of a folder in ClearCase Explorer.)
cleartool diff file.c##/main/LATEST file.c
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).
In my current working environment, I make use of eclipsed files extensively for testing purposes. When it comes time to formalize things, I have a script which generates a diff by comparing the file with a backup saved by my eclipse script.
I'd like to be able to work without the backup of the original file; is there any way I can retrieve the current version of the file that I can pass to diff? Even though the file is view-private, I see I can enter foo##/ and see a list of versions, but I'm not sure how to find which version is the latest. Everything I've tried using cleartool ls or describe with the file name tells me that it's not a VOB object (which is true, although cleartool ls does show it as eclipsed, so it must know, somehow, that there is an element there)
Thanks
Eclipsed file means dynamic view.
The simplest solution would to make a second dynamic view based on the same config spec.
Considering how cheap and quick those views are, this isn't an issue.
On that second dynamic view, you can do a
cleartool descr -fmt "%Xn" /path/to/element
In order to get the extended pathname of the file (see fmt_ccase for more on the %Xn syntax).
I currently have a jacked-up delivery from a child stream to a parent in ClearCase. If I try to undo the delivery it tells me I can't because the "integration activity has checkins" or "checked in versions".
If I try to resume the delivery it says it encountered an error attempting to checkout or merge an element, but doesn't specifically tell me which one.
So I'm looking for a way to either:
Manually stop the delivery (undo all checkouts in the parent stream?)
Find out what element is causing the delivery problem (is it same as the one causing the undo problem)
or Find out what element is causing the undo problem and find a way to undo the checkin (I don't know how to do this. I tried to delete a version in the version tree, but I don't have permission).
For 3/ "Find out what element is causing the undo problem", this is easy (but not recommended): you need to remove all the checked-in versions done during the complete phase of the deliver.
And that is by far the most dangerous solution, especially if any type of activity (other checkins, baselines, ...) has been done on the destination Stream (the stream to which you are delivering file, ie the Stream with the view you are using to deliver to)
You can see those checked-in file by describing the deliver activity (which always starts with deliverbl.xxx)
cleartool descr -l activity:deliverbl.xxx#\myPVob
1/ and 2/ are linked.
A good solution to easily detect the issue is to resume the deliver graphically: open the ClearCase project Explorer (clearprojexp), right-click on the source Stream and select deliver (Baseline or Activities, to default or alternate target: it doesn't matter).
ClearCase will detect that a deliver is in progress and will propose to resume.
All you need to do is check all the files with a red circle and white cross (not the files with a yellow warning sign, those are not blocking the deliver).
Once you have one of those files, right-click on it, and select "display element merge": you will have a more precise error message that you can copy-paste.
If those files are in lost+found directory, all you need to do is to edit the config spec of the view used for the deliver, and add a non-selection rule to avoid selecting anything from lost+found:
cd /path/to/your/view
cleartool edcs
#add at the start of the config spec
element /myVob/lost+found/... -none
Then resume again your deliver, and you will see that those 'lost+found' files become ignored (with a warning non-blocking status attached to them).
If those files aren't in lost+found and are failing the deliver because of "Not a vob object <directory name>", the first check to do is to go to the parent directory of said files in a shell session and type cleartool ls: you will see their status.
In this case, the OP Ian reports them as hijacked, so it was simply about undoing their hijacked status.
He reports also having to delete (rmname) some binary files, although my answer to the question "Clearcase UCM is trying to merge pdf files" is pointing to an alternative solution (copy merge).
My recommendation: in that particular state (deliver with checkins already there), try hard to complete the deliver, not to cancel it.
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.