We are working in multisite UCM environment.
In while my colleague was trying to rebase stream and he was prevented from doing it as there was already a delivery was pending in that stream.
Now in his view that rebase activity is set by default.
After the delivery is accepted in master replica, some one else has rebased the same stream.
Now my colleague is not allowed to rebase as the stream is update. But while we were trying to change the default activity from view properties , it doesn't allow and saying that rebase in progress.
Will it automatically corrected after synchronizaztion? or it will be keep on occuring , why it occurs and how to solve it?
If you are dealing with snapshot view, the first thing to do is a full update (from the root directory of the view)
You also need to check the rebase status of the Stream you are (and on the right site depending on where the rebase was actually started, in order to take into account the multisite aspect).
cleartool rebase -status -stream yourStream#\YourPVob
As long as that status says a rebase is in progress, it needs to be completed (especially if it was in its "complete" phase: cancelling a rebase can fail for a variety of reason: see technote 2059393).
That status will mention the name of the view currently affected by said rebase.
Related
Is there a way to list all files modified since last deliver with clearcase ?
I'm using clearcase like this :
ct setview <myStreamName>
Then I work on files. But before deliver to integration stream, I want to check all modified file. Is there a way to list all file with pending changes and compare them with working revision ?
Edit :
<myStreamName> is a child stream with activities, created from integration stream.
Actually, that isn't quite right. The simplest way to see your pending changes is to run cleartool deliver -preview -long while set in your development view.
This will list all the undelivered activities and the versions on those activities, regardless of the component.
You can use diffbl, more or less, but you then have to delve into the mysteries of deliverbl baselines (created on every deliver operation listing the activities delivered in that deliver.) and use those baselines as a filter on the activities... This then gets more complicated because you can deliver the same activity multiple times if you delivered it, did more work on it, and then haven't delivered the additional work.
Just use deliver -preview -long...
setview will mask your current view, since you access your files directly through /vobs/yourVobs/.../yourfiles (as shown here).
If you are doing a deliver, that means you are using UCM and have set a baseline from your current view, on your current stream (that you are about to deliver to an integration stream).
If that is the case, do a diff between two baselines: (cleartool diffbl -ver baseline1#\apvob baseline2#\apvob)
the latest one of the integration stream.
the one you have set
For the first element, use a ct lsbl -comp C -stream S to get the latest baseline.
This assumes you are delivering one component.
I also mention deliver -preview in "ClearCase Inter project delivery": it needs an UCM view on the target UCM stream to operate.
See also "I need a list of all the component of a certain stream that still needs delivery to default".
The error message:
Error: Target stream "myStream" requires child development streams
to rebase to recommended baselines before performing deliver operation.
means the deliver policy "Require development stream to be based on the project's recommended baseline(s) prior to delivery)" is in place.
See "How to force rebase before each delivery?"
Try and change that policy, or, as enforced, rebase first.
Then do a deliver -preview.
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.
We were trying to rebase our stream.
After click on complete we got issue like some thing is corrupted. [Sorry my collegue did not take the screenshot of error]
we tried to redo the rebase operation.
It said unable to collect information about view
When we try undo rebase we got following error.
Rebase Stream
---------------------------
Error cancelling rebase of stream 'IELoc--Dev100'.
Integration activity change set is not empty.
---------------------------
OK
---------------------------
How to complete or undo the rebase now?
If you are in the process of cancelling, there is no going back: you must proceed all the way to completion of that "cancel" operation.
The technote "Rebase fails with error: integration activity change set is not empty" can give some elements to resolve the situation.
The problem can occur when other external operations have been done during the rebase: a cleartool rmver (delete version), for instance, would be very dangerous.
The idea of a cancel (of a deliver or a rebase) is to undo checkout all the versions previously checked out in order to be merged.
You need to make sure all those versions can be checked out: sometimes a right issue can prevent the unco, sometimes, the version was already checked in.
Now, if the activity associated with the rebase is actually empty, there is an utilty called 'ucmutil' which can reset the rebase state, making it "vanish".
But that should be used with caution, and under the supervision of IBM Rational Support.
See "Canceling UCM rebase fails with error: cleartool: Error: Rebase in progress on stream" and "About ucmutil".
Maybe this is a very basic question: I have notification that a developer has completed with his work.
But the developer hasn't rebased his stream with the recommended baseline.
Now before I want to do a "Deliver from Stream -> to default", I want to rebase his stream, which I can't do because of permission issues.
What should I do to overcome this?
Should I make an integration view in this stream to do the rebase?
Would I be then able to do "Deliver from Stream -> to default" correctly?
Merge conflicts are not present.
Anyone can rebase a stream: you just need your own view on the stream you are rebasing (not on the parent stream: on the destination stream).
But a rebase isn't a deliver. You should rebase first. Then deliver.
The deliver will require the same thing: you need a view on the destination stream (here the stream to which you are delivering to)
In both cases (deliver or rebase), to avoid any permission issue, make your own view on the streams you want to change: I would recommend making a dynamic view for those operations: the rebase or deliver will complete quicker using those type of views (ie, dynamic ones).
(And speed would matter, since ClearCase is so slow, as detailed in this question, and in this article ;) )
Consider a single stream UCM project in ClearCase.
Each developer works in her own snapshot view on the integration stream of the project.
According to the ClearCase documentation when a developer completes an activity, the changes made by the activity become visible to the rest of the developers.
When developer A completes an activity P, are the changes of P immediately visible to developer B and C?
Or do B and C have to refresh their snapshot view in order to actually see the changes?
For a snapshot view (UCM or not), you always have to "cleartool update" your view in order to see the changes committed by your colleagues.
Note: the notion of "completing an activity" might suggest that you are actually using ClearCase with ClearQuest (which will check-in all checked out files associated with an activity, when the related ClearQuest work item is "completed").
This is valid for single-stream UCM projects as well as multi-streams: every time you have several snapshot views on a single stream, you need an update to see your colleagues' commits.