I have a clearcase view which I have not updated in quite some time. It has some view private files and I am sure a lot of other things as well. Is there anyway I can delete all the content of the view and force clearcase to give me everything again?
When i try to build the project from my view (After a rebase) I get a lot of build errors, but if I build the project from the actual stream, I get no build errors at all, so I am guessing my view is a bit messed up, and as I have no files I need to keep there, i would very much like to just reset it.
EDIT:
I am using a snapshot view
First of all, you need to make sure that that your config spec reflect the config of your UCM Stream.
If we are talking about a snapshot view, simply delete everything in it (except the hidden view.dat file), and type (at the root directory of your snapshot view):
cleartool setcs -stream
That will force the view to:
rewrite its config spec in accordance with its associated Stream
launch an update of your snapshot view.
Related
When I am trying to check in a file in ClearCase, I receive an error:
cleartool> ci -nc 1234.txt
cleartool: Error: Branch not consistent with stream attached to current view.
cleartool: Error: Unable to check in "1234.txt".
Does anyone know what's causing this? It started happening this morning.
So far, I have synchronized the stream and the view with no luck. Please help.
If so, what activity? - tied to a CC activity that is associated to an old stream, CQ activity is tied correctly
That means it is an UCM project with CQ integration.
When I look under version tree of this element, the element checkout is under a branch that is different from the stream the checkout was initiated from??? How can that happen?
That can only happen if the view used for the checkout had a different config spec than the one generated from the UCM stream. It is best to undo that checkout, and start again in the proper view.
Well, all I can do is add questions:
How old is the checkout?
Is it on a NON-UCM branch?
If so, when was the component added to the stream's configuration?
If you describe the version, is it associated with an activity? If so, what activity?
Has anything else "odd" happened to the view of late? (restored view from backup, etc.?)
What you're probably going to need to do is do a ct unco -keep. This will undo the checkout and make the view look at the version selected by the current stream configuration. Then
Set an activity
Check out the file again
Verify that the version created is on the current stream's branch
Copy the .keep file to the checked out file
Check it in.
As I see it, just create another new view on required Stream and copy the file into it.
I have a huge clearcase snapshot view including about 10 VOBs, and it takes more than an hour to update the whole view.
Now I'm trying to change the config spec a bit to select several file elements with another timestamp. But by default, changing config spec will trigger a whole view update which is really slow. What I need is just to update the file elements with the updated timestamp.
I read through the official document about cleartool setcs, and also googled some time but it seems impossible. So Here's my question. Is it possible to change config spec of a snapshot view but only update partially?
Actually I also got a workaround here.
I opened the snapshot view in ClearCase Explorer, changed the config spec, clicked OK to update, and then cancelled after the update started. After that, I just updated those selected file elements.
The workaround was OK just for readonly. But I could not checkout/checkin because of the abort of update. The following error popped up when trying to checkout. So I had to update the whole view again.
An update appears to have been aborted or errors were encountered during an update. An update must be performed on the element to enable
a checkout.
Hence, here's another question. Is there any "brute" way to avoid the error for the workaround, since I know the config spec change won't affect other elements?
Besides, any other idea or workaround to solve my problem is absolutely welcomed.
One workaround would be to use a dynamic view (at least to try different config specs and check that the right versions are selected, before using that config spec on a snapshot view if you must.
Another approach is to use 10 snapshot views, one per Vob, because you can update them in parallel, making the all process faster, and starting some of the checkouts faster
I'm looking at a scenario where I have an offline clear case view and I modify files in this view clearing the read-only attribute (hijacking) on the files I modify then several days later I take the view online and need to get my offline changes into the stream.
What I would do is check out the hijacked files and check them back in (merging when necessary).
Is it always safe to work this way?
Is it possible that while adding my changes I would accidentally overwrite other people's changes done while I was working offline?
Any recommendations on how to use ClearCase offline?
Thanks!
(I'm asking because a college says that this offline way of working can lead to overwriting other's changes, specifically in cases when one updates ones view after working offline for a while before converting the hijacked files into checkouts. He says it won't event propose to do a merge in some cases, just completely overwrite the contents of the element being converted with the contents of the hijacked file)
No you won't override anything while working offline.
ClearCase has a reconcliation mechanism for a snapshot view, which, when you get back online, will allow you to:
search for all hijacked files
checkout those files
then checkin them, which is when ClearCase will prompt you for a merge, if any new version has been done on that file during your time offline.
That merge will be a three-way merge with:
root version: the version before any modification by you or other
source version: the matest checkin version (done while you were offline)
destination version: your current file
What about setuping a private branch, working on it, hijacking there files and then merging your private branch on the main branch?
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).
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.