I already have a dynamic view created for me. Ideally, what I would have liked instead is a snapshot view with the exact same config spec.
I have two questions in that regard:
do I have to create a separate snapshot view (with a different tag name) or can I piggy-back on top of the dynamic view to create a snapshot on my local disk? (without using mkview again).
if I do need to run a separate mkview to create the snapshot view, would I have to provide the mkview -sna with a different -tag, -hpa, -gpa and a different snapshot-view-pname ?
would it be transparent to my co-developers whether I am working in a snapshot versus a dynamic view?
do I have to create a separate snapshot view (with a different tag name) or can I piggy-back on top of the dynamic view to create a snapshot on my local disk?
No: you need to use mkview (-snap) again, in order to create a separate view, a snapshot one with a root folder on your disk.
See "Proper 'cleartool mkview' for ClearCase Snapshot view creation", assuming we are talking about a base ClearCase view, not an UCM one.
But then you can re-use the same config spec, at least the selection rules part (since a snapshot view has loading rules specific to its nature, a dynamic view having no need for loading anything: see "Config specs and Load rules difference").
You can copy them from a cleartool catcs -tag <dyn-view-tag>, and paste them in a cleartool edcs -tag <snap-view-tag> (best done from within the root folder of the snapshot view).
(an UCM view, snapshot or dynamic, would not need that, as it would be created with -stream, getting the right selection rules based on the foundation baselines of that associated stream)
would I have to provide the mkview -sna with a different -tag, -hpa, -gpa and a different snapshot-view-pname?
The tag would be different for sure, hpa (host storage pathname) and gpa (global storage pathname) also in that they would end with <tag-name.vws>, the view storage folder named after your new view tag name.
would it be transparent to my co-developers whether I am working in a snapshot versus a dynamic view?
Yes: when you finally check in a file (in a dynamic or snapshot view), your collaborators would see that check in at the same time.
However, if your collaborators are themselves checking in some files, you would not see those updated version (assuming you are working on the same branch) until you cleartool update your own snapshot view.
Related
Currently we use ClearCase UCM.. I am trying to evaluate possibility of using git in our project. I decided to create large repo with past three years changes from an integration stream. The pvob has 12 vobs under it. For purpose of evaluation(creating a worst case), I am putting all changes into single repository.
I want to create a base clearcase view and then adjust its spec for every baseline on the pvob. This will then synched to git repository.
Question in short: How can I create a base clearcase view given a pvob base line and keep changing its config spec to match every baseline?
(academic note : A picture of what I am trying to achieve.. )
(Approach discussed in ClearCase UCM: Is it possible to have a temporary view on any given baseline? is kind of work around in my case. I guess I can avoid the step of creating many temporary streams- not sure how!)
I am putting all changes into single repository.
This isn't the right granularity for a git repo.
Having done multiple ClearCase to Git migration, the right scale usually is one UCM component equals one Git repo.
How can I create a base clearcase view given a pvob base line and keep changing its config spec to match every baseline?
You don't have to create a base ClearCase view.
You can create a sub-stream to the Int stream, and manage the baselines you want to see there.
(cleartool rebase -bas xxx#\YourPVob)
You can then use an UCM view to that sub-stream as a source for your git import.
If that approach isn't possible (as I explained in my previous answer you mention, because for instance all baselines haven't been created in the same parent stream), then you can create a base ClearCase view and modify its config spec in order to select the baseline complete ids:
element * BaselineId1
element * BaselineId2
...
(A dynamic view here is more useful to tweak the config spec.
Once the config spec is set, you can update a snapshot view with the same config spec, and appropriate load rules, to use it as a source for your git import).
You need to make sure those baselines are:
full baselines (you can promote an incremental one to a full one)
referenced with their id (not their title, which is their visible name).
See also "Display Current Baseline with Cleartool":
cleartool describe -l baseline:aBaseline#\aPVob
cleartool descr -fmt "%[found_bls]CXp" stream:myStream#\myPVob
The second command would give you all baselines in a stream.
In both cases, you would see the baseline ids in addition of their names.
I have mention the ClearCase to Git migration aspect in :
"Migration from UCM ClearCase to GIT"
"How to integrate ClearCase development history into Git?"
"Save history from ClearCase to Git?"
"How to bridge git to ClearCase?"
"Sync GIT and ClearCase"
A good trick is to use:
git --git-dir=/path/to/git/repo/.git --work-tree=/path/to/ClearCase/view add .
That allows you to consider the ClearCase view as the working tree of your git repo (which is the destination of your import).
I generally don't try to import all baselines from all streams because it is too complex too soon (in order to get the sequence of those histories right).
I just get a few baselines from the main stream, import them and go from there (keeping the ClearCase referential as a read-only archive source for history research).
I need to create a tar of only a set of files (a.c, b.c, c.c) obtained from the ClearCase repository.
I need all latest versions of those files, and I am writing a script to do this.
How can I do it?
Should I create a new static view with a modified config spec and then do a tar?
If so, how can I select only those files to appear in the view and not the entire code base?
You can create a snapshot view with a config spec like:
element * /main/LATEST
load /vob/path/to/a.c
load /vob/path/to/b.c
load /vob/path/to/c.c
(I am assuming here base ClearCase, not UCM ClearCase)
That would only load the relevant files, with the LATEST version selected.
You can script the creation of a snapshot view (to do only once) with the cleartool mkview command.
See examples in this answer.
See also "What are the differences between a snapshot view and a dynamic view?":
if you have a dynamic view with a simple config spec:
element * /main/LATEST
Then you wouldn't need to load files, only to mount the vob: all the files would be available.
That can be a solution too.
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.
I have seen in ClearCase that there is a Snapshot view and a Dynamic view. What are the differences between these types of views (I'm assuming there are only two types of views) and when are the appropriate times to use them?
Snapshot views are based on the local filesystem (like a workspace in Subversion):
you load files anywhere you want on your hard drive
you have to 'cleartool update' to refresh its content
Dynamic views are based on network content: they represent the dynamic (as in "always refreshed") view of a network content (the remote VOB versions selected by the config spec)
you access them only through the "dynamic view" mount point (M:\ on Windows or /view on Unix: it is a MVFS mount point: MultiVersion Filesystem)
you don't have to refresh them
See the second part of this SO answer for a discussion on when to use dynamic views vs. snapshot.
I often use them (the dynamic views) in addition of snapshot views, meaning it is a great tool to just "see" the files (you can for example use a dynamic view to tweak its config spec until you see what you want and then copy those select rules into your usual snapshot view)
I wonder how I look at a checked out file from another view.
We are using dynamic views and I can see other views checked out files using clearcase version tree so I think it should be possible to specify in a config spec.
When I check out a file I can see the following information.
cleartool lshistory
"20100312.133301" "userid" "/vobs/.../.../File.cpp" "/main/<bransch>/<my_task_brancsh>/CHECKEDOUT" "checkout version" "checkout".
Normally, you cannot directly access a CHECKEDOUT version, since the actual content is stored locally (for snapshot views) or in the local View Storage (for dynamic views).
The ClearCase server knows about the CHECKEDOUT status (which is why you see it in the config spec), but won't have its content.
The only way you could access a CHECKEDOUT version would be:
if the file has been CHECKEDOUT in a dynamic view
if you can that remote dynamic view from your workstation
Then you will actually see both the dynamic view and the storage space of that dynamic view (which, for dynamic views, contains private files and checked out files)
In short, the only way is to somehow access "the other view" (impossible with snapshot views unless you have a physical access to the workstation where the view has been created, possible with dynamic views which can be "mounted" on any ClearCase client)