In Rational ClearCase. I have updated a file without doing check out, after updating it asked me that it is in read only mode still u want to make the changes , and by mistake I clicked on yes.
After that, I realised the mistake and checked out the file and then checked it in, (say version 4).
Again, I checked out the file and made some changes and checked it in (say version 5).
Now, when I am viewing the version history of that file, this version 4 is not getting displayed, version 3 and then just the version 5, but when I compare version 5 with previous version, then it is compared to version 4.
How can I make this version 4 to appear?
The OP mentions:
I think I have checked in this file in the branch, before updating the main branch file, and so this is causing this problem.
That is probable, and would explain why V4 is not visible in the main branch.
One way to ensure that, is by looking at the cleartool lsvtree (text), but also looking at the result of:
cleartool ls /path/to/parent/directory
(the parent directory of the file)
You can see all the selected version, and compare them with your config spec.
Original answer
This (modifying a file without checkout first) can only be possible in a snapshot view (not a dynamic one), and leads to an hijacked file.
You have correctly resolved the situation by a checkout/checkin.
However, if the version selected at the time of you checkout was not the LATEST (but version 2), then V4 would follow V2.
If you have mixed order versions, one way to get back to a stable situation is to:
update the snapshot view, and check that you are in LATEST on that file.
merge your last modifications (V5) to the current LATEST version
If you have a missing version, that could be because it exist in its own branch (which is not selected by your current config spec). A graphic version tree should display it (with the -all option).
cleartool lsvtree -all --graph /path/to/File
Related
From a snapshot view using base ClearCase, I want to checkout the latest version of a file from a branch that is NOT selected in my snapshot view. I would expect this to be possible, because you can do it from the version tree browser tool.
However, the documentation for the checkout command claims that you can't do this in a snapshot (emphasis mine): [edit: Yes you can! See below.]
Nonstandard checkouts
By default, the checkout command checks out
these versions:
The most recent version on a branch, if you are using a dynamic view
The version currently loaded in the view, if you are using a snapshot view
To modify a different version, you can either use the –version option or create a subbranch at that version. (See the mkbranch
reference page). Furthermore, from a single view, you can have only
one checkout per element at a time.
Note: When you work in a snapshot view, the only version of a
directory element that can be checked out is the version currently
loaded in the view. Therefore, the –version and –branch options do not
work.
How can I check out an unselected version from the command line?
[edit: Here I misread the "Note:" section. What the help means is that directories can't be checked out using the -version or -branch args, but normal files can be.]
The actual solution selected by the OP dss539 is to use cleartool checkout directly (see cleartool checkout man page)
cleartool checkout -bra/nch branch-pname | -ver/sion
It would work for files (not directories) in dynamic or snapshot view.
If you don't want to modify the config spec of your current snapshot file, then you can:
either use a separate view (a dynamic one in order to have the right version immediately selected), and modify at will the config spec of that other (dynamic view),
And copy the version back to your snapshot view.
See also "How would you select versions from a specific branch in ClearCase?" for config spec example.
...
Actually, you don't even need to modify the config spec of that dynamic view:
You can use the extended pathname of the version you want to directly access and copy the right version.
or use the cleartool get command (which is what "Send To" is doing on the version Tree).
See "clearcase command to backup predecessor version of a file?"
(You don't need a separate view here)
I have checked out a directory, modified some files and checked in the directory
Is there a way to revert back the checked in directory and start with original directory
Thanks in advance.
Never delete a version, this is way too dangerous (in that it removes all metadata, and hyperlinks attached to it).
Do a subtractive merge, in order to cancel the contributions recorded in your last directory version.
See in IBM the articles "To remove contributions of some versions".
You can see an example of a cleartool merge -delete in "Undo remove file in ClearCase"
You may try to delete the version. In the version tree, right-click the bubble of the current version and choose "delete". The version tree will automatically refresh and fail to do so, because the version it tries to display does not exist anymore. After an update you should see the old version.
If you have edited multiple files, you will have to do this for each file. I haven't found a way to do this by command line, but then again I haven't looked thoroughly ;)
we have delivered some set of packages to testing team and they completed testing.
In one of the package they report a defect and it was fixed and delivered to integration stream. But while deliver it asked for rebase and delivery contained reabase activity.
In rebase activity due to merging issues one of the file was modified in a package which had no defect.
As testing was already completed and the changes in the delivery is not required , our team wants to delete the latest version of a file [which is added as inadvertent] in integration stream.
If i delete the version of a file , will it have any ill-effect? ( For ex. while doing rebase again)
Deleting a version is almost never a good idea.
If that version has any hyperlink: don't delete it!
(You can see it by looking at its version tree: look for any red arrow coming to or going from that version)
If that version has any tag: don't delete it.
That label is probably the result of a baseline, and that would break the integrity of said baseline.
I would recommend checkout that file, and replace its content with the right one, before check it in back in ClearCase.
See also:
"How do I undo a checkin in ClearCase remote client": rmver is dangerous
"How do I roll back a file checked in to Clearcase?": a subtractive merge is preferable to restore the right content in a new version
I baselined a stream this morning, but someone made changes to a couple files that they did not want included in the baseline.
I used the Version Tree to move the label from the newest version to the previous version. (First, was this wrong?)
I then delivered that baseline to a stream in another project. It works fine, and all the correct versions of the files came over. However, now the file in view is version 22, and there is a version 23 that I am not able to see. (I would like to see the newer version, even though I did not want that included in the baseline.) Is there a way to make the view show the latest version of the file?
Note: I tried making a new baseline, but ClearCase included version 22 in the baseline instead of version 23...
The correct course of action, when a Baseline doesn't reference the right content, is:
to fix that content (delete as in "cleartool rmname" the files you don't want to see, checkout/checkin the files you want to fix, creating new versions)
make a new baseline (you can take the same name, or 'title': ClearCase will generate a different baseline id based on that name: BLNAME.xxxx: see "What is the difference between Full baseline and Incremental baseline in Clearcase UCM?")
Moving a label is not a recommended solution (it is actually supposed to be impossible if that label is linked to a Baseline)
You then deliver that new baseline to any other Stream you want.
But if the source Stream has some new version, then you will need to make another baseline including said new version, and deliver that new baseline, in order for your destination project to see and reference it.
Ours is a typical implementation of clearcase UCM :
I have 2 UCM projects each of which represent a release for us. proj2 being created from a stable baseline from proj1
proj1 and proj2 work in parallel and sometimes same elements in both get changed simultaneously. So files a.java lies in both projects and is being worked upon by developers at both. A weekly merge activity happens where downstream gets the latest from upstream project and merges are reconciled.This is my easy life.
As a part of restructuring code, team with proj2 has started moving elements (files mostly) to other places. When I say other places this could mean within the component or to a different component VOB. This has never happened before.
The actual problem:
When an inter-project merge happens, the destination branch version of element a.java could have been moved to a different location/folder. How do I ensure clearcase still merges it with the version coming from upstream project. Is using the cleartool move command enough for clearcase to know and merge at the right place ? For inter-VOB movements, will cleartool relocate command do the same for me. I am in a tightly controlled environment else would have created a sandbox and tested it myself.
I am banking #VonC or #Tamir :)
When I say other places this could mean within the component or to a different component VOB
Note that with UCM, you cannot move elements to another component without re-creating completely said element (new history).
-For inter-vob component refactoring:
I would rather mirror the refactoring in proj1 (in a special Stream) and then attempt an inter-project merge from that stream, rather than hoping that a merge from an old directory structure to a new refactored directory structure goes well.
For outer-vob component refactoring (new history)
A manual merge is safer in that case.