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)
Related
I'm trying to create a new snapshot view (from the command line) and load the vob, preserving timestamps. After the view has been created, I edit the config spec as needed, followed by the line:
load /vob/myvob
On save, it prompts me:
Set config spec and load snapshot view "myviewname"? [yes]
Upon typing "yes", the vob gets loaded with the current timestamp. Since I prefer it to be loaded with the timestamps preserved, my workaround is to delete the contents of the vob, and then from the command line call:
cleartool update -rename -ptime -force
where the "ptime" flag tells it to preserve the timestamp of the file.
Is there a simpler way to do this with the "load" command within the config spec?
EDIT: I'm using ClearCase 7.1.2.4 on Solaris 8
You can use the '-ptime' option to 'cleartool mkview'. See:
http://www-01.ibm.com/support/knowledgecenter/SSSH27_8.0.1/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_mkview.htm
You can check the Clearteam Explorer preferences:
Preserve version creation time when files are updated or loaded from the server
By default, the last modified time of a ClearCase element is the time when the element was last loaded, updated, or restored.
To specify the modified time of the element as the last modified time of that version in the VOB, click the Preserve version creation time when files are updated or loaded from the server preference.
Note that this preference setting can also affect an Undo Checkout or Undo Hijack operation.
Undoing a hijack operation reloads the corresponding version from the server and restores the last modified time as specified by this preference setting.
Likewise, undoing a checkout operation restores the corresponding version of the element and also restores the last modified time according to this preference setting.
Note: you have the same option for ClearCase 7.1.x.
From the main menu bar, click Window > Preferences to open the Preferences dialog box.
If you are using the Rational ClearCase Remote Client for Eclipse, select Team > ClearCase Remote Client > ClearCase Explorer,
If you are using the Rational ClearCase Remote Client, select ClearCase Remote Client > ClearCase Explorer.
To specify the modified time of the element as the last modified time of that version in the VOB (instead of the time when the element was last loaded, updated, or restored), click the Preserve version creation time when files are updated or loaded from the server preference
On command line firstly, create empty view with the following command:
cleartool mkview -snapshot -tag <tag_name> -vws \\<computer_name>\<views_folder>\<view_name> <path_of_localstorage>
Then load it based on the config spec with the following command:
cleartool setcs -force -overwrite -ptime <CS_Folder_Path>\<CS_File_Name>
For details you may follow this link.
Is there a ClearCase equivalent to hg shelve (or git stash for those of the other persuasion)? The closest I can think of is doing uncheckouts and saving keep files, but that means I'd have to hunt down the keep files afterwards, re-checkout the files and merge. I realize that ClearCase and Mercurial/Git have different philosophies behind them, but I'd be interested if there is any work in making ClearCase more "usable".
I listed a few for other version control tools, but none for ClearCase.
I explained, for ClearCase UCM, that a shelve command isn't easy to implement.
Instead of just saving the .keep files, you could save patches (unix diff between a .keep and its original version), since a patch can be re-applied later.
The other approach is to modify the config spec (easier when in a non-UCM view) in order to checking the currently modified versions in a new branch (see this config spec)
You can then decide to merge that branch later.
The philosophy is quite different.
In Clearcase, if you need to work on another branch/release, you usually have to use another Clearcase view. If you have Clearcase/UCM, it is even more true as you would use another view attached to another UCM stream. You would not be able to use the same view, whereas in Git, you would be able to stick to the same clone and perform a git stash, git checkout in order to start working on another release.
Now let's assume you need to work on another feature, for the same release. Under Clearcase/UCM, you would be able to create a new activity (cleartool mkact) and work on this new activity, using the same view. All the changes made will then be associated with this new activity. You will also be able to switch back to the previous activity using the command cleartool setact. The tricky part is if you need to deliver the activities separately. This will not necessarily possible as you might need to deliver both at the same time depending on the content of the changeset. This doc about determining dependent UCM activities is quite useful. If you need to move some changeset between activities, you can use the command cleartool chactivity with -fcset and -tcset options.
As a summary, with Clearcase UCM, if it is for different release, switch views and streams. If it is for the same release, play around with the UCM activities, knowing that it is less flexible than git stash.
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
with ClearCase UCM I can create a baseline in a snapshot view directory. When not all files are up-to-date, which version of a file is included in the baseline?
Example: version 3 of foo.txt is located in the snapshot view directory and there already exists a version 4 of this file. Which version of the file is referenced by the baseline?
Does this depends on the version of ClearCase (I am using ClearCase 7.1)? Do I have to consider something?
Background of the question: for a continuous integration build I want to use a snapshot view. When during creating or updating the snapshot view an other user checks in a file to the same stream this new version may or may not be part of the snapshot. At least I want be to be able to identify which files in my snapshot directory have been used by the build.
About Baselines: A mkbl depends on the selection mechanism (the config spec)
of the local access mechanism (snapshot or dynamic view) providing said selection mechanism.
For each element in the component, the baseline records the version of that element selected by the stream's configuration at the time mkbl is executed.
So the -view parameter is only there to reference the Stream (and its associated config spec):
-vie/w view-tag
Specifies the view from which to create baselines. Baselines are created in the stream that the view is attached to.
For example, if you are working in coyne_dev_view, but want to create a baseline from the configuration specified by the view coyne_integration_view, use -view coyne_integration_view.
This option creates a baseline in the project's integration stream that includes all the checked-in versions contained in coyne_integration_view.
If you do not specify view-tag, the current view is used.
In your case, if your UCM view is supposed to select v4, but is currently selecting v3 because that snapshot view hasn't been updated yet, the baseline should reference v3 (what is currently selected by the view).
So for your background question, best to perform a cleartool update before the mkbl.
How Can I Revert to Earlier baseline? We have a UCM parallel development(multi-stream) project. Each developer have a snapshot view on Project's Integration stream.
Developers want to see earlier version of the application in their snapshot views so They can debug early version of application to find bugs.
When I want to change an existing snapshot views's foundition baselines, clearcase does not allow me. So How Can I do this?
Since you employ the term Baseline, I will assume you are using UCM.
On a stream, you can not revert backward a baseline.
One possibility is to make a parallel stream, with the desired baseline as foundation: this is the quickest way.
After changes on this new stream, you can make a new rebase to change the foundation baseline, but only if that new rebase is using a more recent baseline from the parent stream (not an older baseline)
For your specific need, I would recommand a non-UCM snapshot view with a simple rule
element * thePreviousBaseline
In order for the developer to have:
his/her current UCM view for development (always set on the LATEST of a branch associated to a stream)
a second snasphot view set to whatever baseline he/she needs.
That second snapshot view is completely not-related to the UCM project and takes advantage of the "full" nature of the baseline (do check that your baseline has been put as "full", not "incremental". If it is "incremental", simply change its type and upgrade it to full)
So, beside your current snapshot UCM view, you can create anywhere you want a non-snasphot view:
cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView
cd myPathToRootView
cleartool edcs
[add the selection rule: element * myOlderBaseline]
[add the load rule at the end: 'load /myVob_Including_MyComponent]
[save, type 'yes']
That is fine for consultation/execution, but if you need to patch (that i is to write, check out and in some files), then I would recommend one UCM stream per baseline to be patched.
That way, the stream clearly represents the patch effort for a given baseline. There should not be too many of them, unless you put into production a new version of your application every five minutes... which is not advisable ;)
So to summarize:
the non-UCM snapshot view is unique and serve for a quick consultation/debug of one older baseline at a time.
for patches (source modification), you create a parallel stream properly named, with the correct foundation baseline, and then a UCM view on it. You can not only debug but also fix some bugs in an activity, the deliver that activity to the main Int stream if that bug need to be retro-fitted on an higher stream.
(note: all bugs do not always need to be delivered: they can be obsolete when compared with the current state of the development)
The way I have solved this problem is by making another Stream, a child Stream of the Integration Stream. The easiest way to create this Stream is to open ClearCase Project Explorer (not Rational ClearCase Explorer) and navigate to the Project and then the Stream in question. Right click on the Integration Stream and select "Create Child Stream..."
Click "Advanced Options" and select a baseline for each component. Do this by selecting the component and then selecting "Change..." and selecting the specific baseline you want to see. You probably want to select "Prompt me to create a View for this Stream." Select "OK".
Any developer can do this. You don't need to be a VOB owner or Project or Stream owner.
Well, it depends. Actually, the answer lies in setting up your config spec to point to the proper files. Your config spec tells your view which versions of elements to look at. But how you do write it depends on your project's approach to baselines. Did you apply a label to mark that baseline? If so, and if you only want to read and not checkout anything new, your config spec can be as simple as
element * <LABELNAME>
If you didn't use labels, you can also set up your config spec to show you files based on dates. It gets more complicated the more rules you need to add to constrain your element choices. If you have more specifics, I can try to elaborate on what rules you might need. Otherwise, I would read the manuals that come with ClearCase. If you view the Extended Help from ClearCase Explorer, and then do "Viewing Rational ClearCase Manuals On-Line" it should give you some links to the Command References. This is where I go whenever I need to modify my config spec in some new way.
Also, note that we only use dynamic views, so I don't know if snapshot views work differently.