Somehow one of my checkouts in UCM has no activity attached to it and when i try to to undo checkout, it says that cleartool: Error: To operate on UCM branch, must be set to an activity and a UCM view. Has anyone come across this kind of scenario? Please advise.
According to IBM we could remove the view and all its references and then re-create it which should solve the issue of the checkout.
Is there a way to find what has gone wrong and any suggestions to fix the issue?
According to IBM we could remove the view and all its references and then re-create it which should solve the issue of the checkout.
Yes, it is the nuke-view approach:
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
Keep it mind it will cancel any checkout produced by that view.
Is there a way to find what has gone wrong and any suggestions to fix the issue?
Maybe the activity was somehow deleted, leaving the checked out version "orphaned" (in term of activity, that is).
An cleartool lshistory -minor on the vob (vob:\avob) for instance, or the element of the file (path/to/file##) might reveal some event which could shed light on this circumstance.
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.
When I am trying to do Undo Checkout through my ClearCase GUI, its showing me a error message as "Error Undoing the CheckOut for "E:\Views\Stream Name\File Name'.
Lock on Versioned Object base "\ prevents operation uncheckout
Unable to cancel Checkout for 'E:\Views\Stream Name\File Name' "
Please suggest me how can i solve this issue
You need to make sure what is locked.
If it is the UCM project for instance, you need to run (or to ask your ClearCase admin to run) a cleartool unlock:
cleartool unlock project:projectname#\pvobname
If this is a file/folder, it is possible it is locked by another user, in which case it can be unlocked at any time, allowing you to proceed.
Adding to VonC's response - it's possible that the vob itself was locked for some reason. Why would a vob overall be locked? If it was being backed up, for example. Someone may have run a "cleartool lock vob:myvob" or similar for some reason. Then ran "cleartool unlock vob:myvob" afterwards. I'd ask your clearcase admin for an explanation.
In UCM project we are trying to deliver activity to default stream.
It is displaying that activity is having dependency with another activity.
As the dependent activity has no useful info we obsoleted it. But still it doesn't allow us to proceed and it force us to deliver that ?
Why dependency is being triggered even if the activity is obsolete?
The activity will be associated with your deliver (without choice) if:
there is a common file with other activities (file dependency)
you previously did a deliver to another stream (in which case it automatically link all the remaining activities together)
If the activity is small enough, the best course of action remains to deliver everything, and to cancel what you don't need.
If there is really no common file, one option mentioned in this old 2003 thread would be to try and change the owner (only by a ClearCase admin) of the activity.
See cleartool project:
cleartool protect -chown aNewOwner activity:anActivity#\aPvob
(you might have to "cleartool unlock activity:anActivity#\aPvob" first if it was "lock -obsolete")
#Samselvaprabu I have seen this happen before, this smells of hyperlinks. Can not be 100% sure if your problem is exactly same, but they have worked for me in the past:
checkvob -ucm activity:#\PVOB
which might point you to a bad hyperlink
checkvob -fix
Use ucmutil to do a similar job
Please be careful, there are always risks associated with messing with hyperlinks, so read the manuals and/or technotes before you actually run a checkvob -fix or something intrusive.
Events till now
We have a CC 7.1.2.2, multisite setup where we do deliveries between 2 sites. Now when resuming a delivery at the destination site, we get this error :
Unable to read change set entry for activity "<activity name>". Unable to
convert diffs to elements. Unexpected error in deliver. Unable to perform merge.
Unable to do integration.
Then running checkvob -ucm shows some broken hyperliniks which the SCM support team fixes for us. IBM tech note says this is a synch issue.
Now the actual problem:
This has started happening on a regular basis suddenly and we know its NOT a synch issue between VOB and PVOB as the packets are getting synched properly. What I am interested in finding out is whether this could occur due to a specific set of user actions like deleting checked out versions etc. The key point is its not a one off thing and impacts our deliveries everyday. We are not able to find any concrete triggering actions or root cause
Any ideas ?
This has been linked to a multi-site sync issue from a long time now (here an example in 2005), and was also associated with a bug in CC multi-site 7.0.
But if you are really sure multi-site sync is not the issue, then it could be linked to "lost+found" issue, where elements could have been:
deleted (rmelem by an admin -- I know regular users in your setup don't have rmver or rmelem rights -- in order to clean the lost+found directory automatically, maybe through a ClearCase scheduled job or some kind of trigger?)
not selected because the config spec of views involved by your deliver are setup to not select the lost+found directory
Found out the issue; it was hidden synch issues indeed. What really was happening was that multisite synch was timing out for packets larger than 250 meg. This would create problems for bid inetersite deliveries where PVOB would synch over and VOBs would not. This was hidden as otherwise sync was happening properly.
Thanks VonC for the other inputs; I know you'd have pointed me to synch issues as a first measure had I not confirmed it wasn't the issue.
In our project so many file changes are happening, I want some notification for every checkin. so that every one in the team can know the files changed in the project.
I want some basic information about the file like comments and the branch.
That means "trigger": specifically a post-op checking trigger:
cleartool mktrtype -c "Trigger to notify on checking" -element -all -postop checkin -execwin "ccperl \\path\to\notification\script" -execunix "Perl /path/to/notification.pl" NOTIFY_ON_CHECKING
You can get some ideas from the "ten best triggers" IBM page.
See also the E-mail notification postoperation trigger script, which is on deliver, but that can also give you a good idea for adapting it for each checkin.