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)
Related
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.
My company has recently switched from using Perforce to Rational ClearCase for version control.
In the P4Win client it was possible to select View -> Entire Depot and browse depot files that were outside my client spec and this was useful for figuring out exactly what I needed to add to my client spec.
Significantly this avoided the need to synch the files from the depot before viewing them, and was therefore quicker.
I'm now using ClearTeam Explorer and can't seem to find an equivalent. I'd like to have this for a similar purpose, to figure out exactly what I need in the load rules for my snapshot view and also to decide what views I need to create.
Does anyone know if it is possible to view what files exist under a project in ClearTeam Explorer without first creating a view on the project / joining it?
ClearTeam Explorer is basically a trimmed down Eclipse with ClearCase specific plugins.
thanks.
The easiest way would be to create a dynamic view (you need to add -stream yourStream#\yourPvob to the mkview command, I know it looks like you "joining a project", but still, dynamic view are quick to setup).
The idea is to configure your config spec with the right selection rules (a dynamic view will display the files instantly), and then make your snapshot view with those same selection rules (and the appropriate load rules, specific to a snapshot view)
Note that, according to the CCRC wiki:
With the Release of v8.0, the ClearTeam Explorer is the common Eclipse UI client that supports MVFS on native clients, as well as webviews.
CM Server in 7.1.x was renamed to CCRC Wan Server in v8.
If you don't have cleartool installed, that means you are using webviews (which are snapshot views with web access to the CCRC Wan server).
In that case, there is no easy way to browse any code from any Baseline (other than joining a project)
FWIW now, wanted to suggest a different solution here.
I would create a web view on the stream with empty load rule.
This will ensure a faster view creation.
Then from ClearTeam Navigator menu, I will enable the options to show
Unloaded VOBs
Unloaded Elements
This will ensure that the unloaded elements chosen from my element rules are displayed in ClearTeam Details and ClearTeam Navigator.
Note: You need to be connected to the CCRC server to view the unloaded elements.
Then I can browse the file structure and decide which files needs to be added to my view's load rule.
Or I can just right click on any unloaded/partially loaded resource and select "Load Resource..." which will load the item to my view.
I'm using only CCRC - I don't have ClearCase locally installed.
I use CCRC Version: 7.1.1 Build id: 7.1.1.03.00_2010C.D100803
I'm working with a mature user of ClearCase - they have hundreds of work streams in a complex child parent relationship tree. When I create a view or stream CCRC offers me a picture of this complex tree and the location of my view (or stream if I'm creating a stream).
However, once my local view is set up there appears to be no mechanism for checking the location of any views. CCRC menus which 'show ClearCase view configuration' only show the load rules (i.e. which VOB's I'm currently selecting).
Another post to Stack Overflow tells me that '.ccase_wvreg' lists the local file paths where local copies of the files are stored. But '.ccase_wvreg' doesn't show the logical name of the views.
So how does CCRC find a map the logical view names and their configuration?
Is there another file I can examine (or other work around?) which would show me the complete view configuration.
The only workaround I have today (other than being incredibly careful and keeping png images of the stream as I set it up) is to commence the process of creating a new view or stream and retrace my steps.
Its surprising that being able to confirm the location of a view is so difficult - given what happens if one mistakenly checks in or deliver to the wrong stream!!
The CLI (Command Line Interface) for CCRC might be able to provide more information, espcially regarding the config spec of your view, in which there should be mentioned the name of the associated Stream.
catcs [-username user-name][-ser/ver server-url][-pas/sword user-password]\
[-tag view-tag]
But check first in the properties of the view. It can also include that information.
One of the shops I'm working at relies on dynamic views in ClearCase. The established norm has been to create a new view for each project effort. Over time I've found that I've only needed to have one or two views concurrently active. I've taken to "reusing" a view by changing the config spec (subsequent to check-in, label, release, etc.). So far, it has worked out. Is there any long-term problem with doing that? If not, is there anyway I can re-name the view (change the view tag) to better reflect what the purpose of the view is?
For base ClearCase dynamic views, the only side-effect you can have when recycling a config spec are private files:
Those are store within the dynamic view storage, and not always removed when the config spec is reset.
You also need to make sure no files were left checked-out: they also are stored in the view storage, and once the config spec has changed, they may not be visible/reachable any more (but you should still be able to unco them through the 'find co' GUI).
You cannot rename (change the tag) of a view (dynamic or snapshot)
And, just to be complete, you cannot recycle the config spec of an UCM dynamic view (which reference a stream).
You can try to change the foundation baselines of said stream, but again, that is not always possible.
I vote for scrapping old views and creating views afresh. Besides all teh great inputs from VonC, from the disk space point of view, old views tend to get bulky over time and you soon you wont be a favorite with your sysadmins :-)
From my experience there is no log term affect for using only 2 dynamic views instead of one for each "project". If you don't need the views active concurrently its a good method, thats the beauty if dynamic views they can be updated very fast and very frequently.
For the renaming part, why rename? make a similar new dynamic view (or two) and give it a new name (view tag).
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)