I am trying to deliver deliver from stream to default in Clearcase. But I am getting below errors. I tried from both Clearcase UI and from Command Prompt.
Find attached screenshot for both
and
First, there might not be a deliver in progress from your source stream, but the activity might be involved in a deliver from another stream: check the deliver status of those other streams first.
cleartool deliver -status -stream anotherStream#\aPVob
Cancel or complete the deliver involving that activity.
The OP Amolb reports in the comments to have seen another deliver in progress, but was able to get the current one going by creating a new integration view and using that one for said current deliver.
If you don't see any deliver/rebase that you can complete or cancel... then the following has to be done with IBM support supervision, but you can clear the deliver/rebase status of a stream or an activity:
For instance, if you see UCM_REBASE in a stream:
cleartool dump stream:yourStream#\yourPVob
/opt/rational/clearcase/etc/utils/ucmutil
ucmutil> setpvar -pvar UCM_REBASE -none stream:yourStream#\yourPVob
You are about to modify internal data. Any mistake will damage the objects.
Do you want to continue? [no] y
Set UCM_REBASE = "" [cleared]
Similarly, for your activity ("The set activity of this view may not be changed until the operation has completed."), you can clear out its "participation status" with a similar process:
cleartool dump activity:rebase.yourStream.20160728.060000#\YourPVob
ucmutil> setpvar -pvar UCM_INTEGRATION_ACTIVITY -none activity:rebase.yourStream.20160728.060000#/vobs/YourPVob
You are about to modify internal data. Any mistake will damage the objects.
Do you want to continue? [no] y
Set UCM_INTEGRATION_ACTIVITY = "" [cleared]
The integration stream being set to an integration activity pretty much tells you there is already an in-process delivery. #VonC 's comment about support supervision is pretty much spot on because you're ClearQuest-integrated.
If you describe and dump the activity that is being referred to, you'll get more information about the source stream, if nothing else by looking at the merge arrows on the changeset. If these are from the current source stream, definitely engage support...
Related
I need to remove the code changes of an activity from the child stream, which is shared among two projects. Wanted to remove code changes from Project A but I need to secure not to lose the changes in Project B
Can someone suggest me the possible solution and the next steps to be taken care to get rid of this issue.
See "Reverse Change set of an activity in Clearcase": you can use ccperl cset.pl -undo, or do for each file in an activity a negative or subtractive merge.
In both case, the goal is to create a new activity whose change set will represent the negative image of the existing activity.
You can then do what you want/need with it, like deliver it to another stream where the first activity was already delivered.
I'm trying to figure out how long on average I take to review files at work. The way our review system works, someone checks a new version in and applies a Reviewer attribute to the file with the name of the reviewer. Then after the reviewer finishes the review, they apply an Approved attribute with the value "yes" or "no".
So to find the time it takes for me to review something, I need to find the difference in creation time of the two attributes. Is there a way to find these creation times in clearcase?
I can definitely get the time the version itself was created using cleartool describe, but I didn't see a way to do it for the attributes.
Attribute creation events are "minor" events what will eventually get scrubbed away (The default is 7 days)...
While they are present, you can find them using cleartool lshist -minor {element name}
How to know details on the status(in-progress or finished) of a delivery from one stream to its parent stream?
I came across this when I was trying to deliver from C stream to B stream. But it throws error that B has a deliver in progress and I have to wait till it is completed.
You won't get any more information than "deliver is in progress" with a graphic deliver (or a cleartool deliver -status)
At most, adding the -l option (-long) would display a list of versions that may require merging.
I like to at least check the current activity in the destination stream (B stream): it will be a deliver activity, which can at least tell you who started the deliver (owner of the activity) and when.
cleartool lsact -stream B#\aPVob -cact
In any case, you would need to complete or cancel the deliver, before being able to start another one.
Or you would need to find the owner of that deliver, in order for him or her to complete or cancel it.
As I recommended before, try to complete the deliver (especially if some merged versions have already been checked in), before trying to cancel the deliver.
Is it possible to open a view (snapshot or dynamic, maybe readonly) on any given baseline (recommended or older) in a stream (integration, development or child) for performing some tasks and then remove the view when done? How?
To open a view to a given baseline, you actually need a view associated to a stream with said baseline as a foundation baseline.
That means you need to rebase that stream first, which is:
not always desirable (since you would need to merge said baseline with current content, and that doesn't always make sense)
not always possible (you can only rebase a sub-stream with baselines coming from its immediate parent).
What is possible is to:
get the stream on which your baseline has been put
make a sub-stream from that stream, taking said baseline as the foundatio one
create a snapshot or dynamic view on it
do your work
put a new baseline, and deliver it to its parent stream
obsolete that sub-stream (and you can delete your view if you want)
Note: you could create a base ClearCase dynamic view (ie non-UCM) with a config spec you could then change as you want, but that wouldn't allow you to checkout and modify any file.
That would only be a convenient way to visualize any baseline of your choice.
I've previously documented my opinions on Clearcase as a source control system, but unfortunately I am still using it. So I turn to you guys to help me alleviate one of my frustrations.
We have just moved from a one-branch-per-developer system, to a one-branch-per-task in an attempt to improve some of the issues that we've been having with determining why certain files were changed. Generally I am happy with the solution, but there is one major issue. We are using simple scripts to start and end tasks which create a new branch named with the username and task number and then updates the local snapshot view to have a config spec similar to the following:
element * CHECKEDOUT
element * .../martin_2322/LATEST
element * /main/LATEST -mkbranch martin_2322
load /Project/Application
Let's say that my project has two coupled files A.cs and B.cs. For my first task I make changes to A on the branch. Then I need to stop working on task 2322 for whatever reason and start work on task 2345 (task 2322 is not finished, so I don't merge it back into main).
I create a new task branch 2345, edit both A.cs and B.cs and merge the results back into main. Now I go back to work on 2322, so I change my config spec back to one defined above. At this point I see the A.cs file from the task branch (as I edited it earlier, so I get the version local to that branch) and the latest version of B.cs from main. Since I don't have the changes made to A.cs on the 2345 branch the build breaks. What I need instead is to be able to pick up task 2322 from where I left off and see it with the old version of A.cs - the one that was latest in main when the branch was created.
The way I see it I have a few options to fix this:
Change the config spec so that it gets files from main at the right date. This is easy enough to do if I know the date and don't mind setting it by hand, but I can't figure out how to automate this into our task switching scripts. Is there anyway to get the creation date of a branch?
Create a label for each branch on main. Theoretically simple to do, but the labelling system in our install of CC is already collapsing under the weight of a few hundred labels, so I don't know if it will cope with one per developer per branch (notice that the task in my example is 2322 and we're only about an quarter of the way through the project)
Merge out from main into the task branch. Once again should work, but then long running branches won't just contain the files changed for that task, but all files that needed to be merged across to get unrelated things working. This makes them as complicated as the branch-per-developer approach. I want to see which files were changed to complete a specific task.
I hope I'm just missing something here and there is a way of setting my config spec so that it retrieves the expected files from main without clunky workarounds. So, how are you guys branching in Clearcase?
A few comments:
a branch per task is the right granularity for modifying a set of file within a "unit of work". Provided the "task" is not too narrow, otherwise you end up with a gazillon of branches (and their associated merges)
when you create a config spec for a branch, you apparently forget the line for new elements (the one you "add to source control")
Plus you may consider branching for a fix starting point, which would solve the "old version of A.cs - the one that was latest in main when the branch was created" bit.
I know you have too much labels already, but you could have a script to "close" a task which would (amongst other things) delete that starting label, avoiding label cluttering.
Here the config spec I would use:
element * CHECKEDOUT
element * .../martin_2322/LATEST
element * STARTING_LABEL_2322 -mkbranch martin_2322
# selection rule for new "added to source control" file
element * /main/0 -mkbranch martin_2322
load /Project/Application
I would find this much more easier than computing the date of a branch.
do not forget you can merge back your task to main, and merge some your files from your finished task branch to the your new current task branch as well, if you need to retrofit some your fixes back to that current task as well.
You can get the creation date for a branch by using the describe command in cleartool.
cleartool describe -fmt "%d" -type martin_2322
This will printout the date and time that the branch was created. You can use this to implement your first option. For more information, you could read the following cleartool man pages, but hopefully the above command is all you need.
cleartool man describe
cleartool man fmt_ccase
We use Clearcase, and we find that creating a branch for a release is often much easier than doing it by task. If you do create it by task, then I'd have a 'main branch' for that release, and branch the tasks off that branch, and then merge them back in when finished to merge them back to the trunk.