I have a problem with some programmers. They don't let me know when they deliver, so I do nothing about it.
Is there a way to get a notice when someone delivered?
Thanks.
First of all: hit them, hard!
Have a trigger implemented on the clearcase server that send on email on commit or on merge.
http://www.ibm.com/developerworks/rational/library/4311.html
"deliver" can mean an UCM merge, in which case you can:
make an intermediate stream where developer delivers whenever they want
simply lock the integration stream in order to be the only one able to deliver on it (meaning you can trigger a deliver from the intermediate stream to the integration stream when you want: if the deliver reports something to merge, then you can examine the activities to be merged).
Related
I am encountering a problem with Clearcase. I do apologise in advance if I am unclear, or redundant since I am quite new to this VCS, coming from a Git background mainly, I might not know how to search correctly regarding my problems.
We have a new version (non-relevant to CC, business-wise) of the application every few months, and we create a new VOB and stream for each version each time. We have a generic stream in which we deliver the last baselines from a finished version, add a new baseline, then export the contents of the generic stream to a new VOB and Stream.
My problem is, being hasty I actually delivered into the the generic stream, not the last baseline, but a previous one. And on top of that, I added a brand new baseline to the generic stream.
I need to be able to deliver into my generic stream, the very last baseline from our previous business version of the application.
(I am mostly manipulating Clearcase project explorer, since I don't really know the cleartool command. I tried to use a few CLI solutions but could not manage to do so, but might be linked to how our Clearcase server is)
In order to do that, I tried to :
Delete the delivery activity. But there is an error when I try to do that : "Error : Cannot remove an activity with versions in its changeset". I tried to bypass this, helping myself with google, but could not manage to do so. I am afraid this is normal Clearcase behaviour, and cannot pursue this way.
Redeliver our last business version correctly, but it did not work because of my newly hastily created baseline in the generic stream.
I would take up on any clue, indication lead, since I cannot manage to find how to correctly advance upon this matter.
Thank you in advance.
It is simpler to:
deliver to the generic stream the right content (on top of the wrong one) and set a new baseline
rename the previous baseline into a "DO-NOT-USE" name
cleartool lock -obsolete the baseline, to make it invisible (rather than trying to delete it)
That way, you can resume your successive delivers/imports of each release, and forget about the wrong one.
If the baseline you created in that stream is the most recent baseline, and has not yet been used by another stream (either pulled in a rebase or delivered to another stream), you should be able to just remove it.
In any event, since your plan is to move forward by delivering a more recent baseline created in the same parent stream to this "generic" stream, you can just deliver the right baseline to this stream, make a new baseline, and optionally lock the previous baseline.
A couple of UCM gotchas you may want to be aware of:
If you deliver a baseline to another stream, the source baseline is permanently irremovable.
ALL deliver operations deliver baselines. If you don't create a baseline, the deliver operation creates a "deliverbl" baseline to deliver.
Removing streams is either non-trivial or impossible.
Removing projects where development work has been done is usually impossible.
For future reference, to remove an activity that is NOT in a baseline:
Describe the activity on the command line to get the list of versions. You may want to redirect the output into a file so you can copy and paste the version info into the next step more easily. To describe the activity, you need to use "cleartool describe activity:{id}#{project VOB tag}"
Remove all the versions in the change set using "cleartool rmver -xhlink {version ID}"
Remove the activity. Since the delivery is apparently completed, the activity should not be set.
This is regarding, IBM Rational Clearcase Explorer application. If we deliver some files, and take the step of "make baseline". After that, if we don't do the "Recommend Baseline" step, will it cause problem for others trying to deliver to the same stream?
After that, if we don't do the "Recommend Baseline" step, will it cause problem for others trying to deliver to the same stream?
deliver, no. Rebase maybe, as ClearCase will rebase by default the recommended baseline of the parent (source) UCM stream.
But for delivering (cleartool deliver), you can deliver the baseline you want.
Since the deliver stream's recommended baseline is selected by default, that could also trip a user not double-checking the exact name of the auto-selected baseline.
Not recommending a baseline will not prevent a subsequent deliver operation.
Please note that all deliver operations are merges, which can cause "merge creep" issues if you use deliver to push changes back into child streams. As a general rule, don't deliver to child streams.
If you get a deliver that says that some file's can't be checked out, it usually means someone else is delivering. Not knowing the checkout error message, I can't tell you that this is what is happening though.
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 ;) )
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.
I found "Suspend Change-set" in RTC to be very useful, and since we're working with ClearCase as well (dozens of users) I'm wondering if that feature is also available in ClearCase as well.
If not - could it be generated by script/trigger/hook ?
We use UCM, and I'd like to explain my question:
if I have to deliver and I want to skip delivering one activity, I can decide not to deliver it (if no dependencies...) , so my question is regarding working on my current stream: Is that possible to "suspend" an activity from my current stream ?
Thanks in advance
Simply put, not easily.
RTC is basically ClearCase rewritten from scratch, and the "suspend" mode (also called stashed or shelve) takes advantage of the notion of applying a changeset (to any state of a repository)
The UCM changeset are a list of versions of files. Each version is tied to its predecessor, and you cannot easily remove it (unless you do some negative or subtractive merges), and then re-apply them later.
That being said, Reuven just contacted me this morning, because he had files in checked out in a snapshot view on a Stream which he wants to rebase (similar issue to your deliver problem).
A possible way to do that is to create another view (dynamic one), which you can use for your rebase, and then go back to your snapshot view and update it: it will detect the updated config spec (following the rebase) and will not erase any of your currently checked out files.
On the checkin, those files will be merged with the updated version.