We have a VOB with about 12 components and we only use component baselines.
They are normally created by using the GUI under Windows (UNIX is only used by some developers, most of them are more familiar with Windows).
Now to create the component baseline you have to right-click on the stream you want to create the baseline in and select 'Properties' before going to the 'Baselines' tab and create the new component baseline there.
The problem is that if you right-click on the stream the menu already has an entry called 'Make Baseline'. Unfortunately it happens (not too often but still sometimes) that someone clicks on the 'Make Baseline' option here and creates a baseline for all components instead of only the one he intended.
I already experimented with some preop triggers of mkbl but as far as I figured out they are not fired when using the GUI in Windows and they cannot prevent the creation of the baseline as the name of the baseline is not know at that point in time.
Is there a way - be it a trigger script or whatever - to prevent the creation of a baseline if it's supposed to be applied to more than one component or will we just have to accept the situation and waste our time - it takes time for someone to discover that there is a wrong baseline on some components and then we have to obsolete the baseline for the wrongly 'labeled' components?
Is there a way - be it a trigger script or whatever - to prevent the creation of a baseline if it's supposed to be applied to more than one component
Not that I know of, considering the project explorer (clearprojexp.exe) directly manages the GUI for creating baselines (it isn't delegated to an exe in <Rational\ClearCase>/bin.
The only (more complex) approach would be a cron job detecting the latest baselines created and, if created in an interval of a few minutes by the same owner, would (if no other baselines have been created since) remove them (with cleartool rmbl) and send an email to the baseline owner.
You can definitely write triggers that work on baseline creation! If your trigger's not firing then there's something wrong with either the trigger definition, or the script it runs.
For a simple test, create a trigger that just executes:
clearprompt proceed -prompt "You're creating a trigger" -mask proceed
If you've done it right, every time you create a trigger you'll get a dialog box come up with "You're creating a trigger" as the message. If that works, then it's your script at fault; if it doesn't, there's something wrong with how you've created the trigger.
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.
I am trying to understand how long ClearCase operations take after performing the add to source control operations.
If I am working through a CCRC snapshot view and I add a file to source control, how long will it take for the changeset to be updated with the new line, and how long until the operation completes will the new file be available under a dynamic view pointing to the stream that the file was checked into?
Is there any way to speed up that process by invoking a manual update of the dynamic view or something?
Regards,
Andrew
how long will it take for the changeset to be updated with the new line
As soon as you checkout a file, selecting an activity, it will update the chenge set of said activity immediately.
A dynamic view would reflect that file only after you check in (through your web snapshot view in CCRC), and that update would also be near instantaneous.
To speed up, you can refresh the dynamic view, or do a cleartool ls in the directory you want to see updated.
In each case, when you are doing a checkout or a checkin through CCRC, you are posting an http request to the CCRC server which in turn complete the operation with the ClearCase Vob/View server.
So once the checkout/checkin is completed, any other ClearCase view (CCRC or not) would be ready to reflect the changes.
The only part which takes time is the communication between the CCRC client and the CCRC server. That server being usually on the same LAN as the ClearCase server, the ClearCase command itself executes fairly quickly.
"fairly quickly" turned out too slow for the OP's need: a postop trigger on checkin.
That trigger use a ClearCase dynamic view on the server side, and has to introduce a sleep on the element checkin (on mkelem) in order for the second call of that trigger (on the parent directory being checked in) to properly detect the new created file.
Theoretically, it should be instant. As soon as the add finishes, the dynamic view should see the new file. In reality, it might take longer due to the nature of ClearCase and its view processes.
Every view has a process running on the view server (local or remote), and this process needs to query the VOB server to get the changes.
In our ClearCase environment, we see many lags that are probably the combination of a loaded server and network traffic.
Bottom line - should be quick (seconds), but not instant. If it takes longer, you should try and see what might be slowing the processes down.
We use ClearCase as control version system.
In our system sometimes we make releases without some developers commits because of time limit.
For example I made some changes in six classes but another user did changes in all or some of them also. And I have to commit code without his changes. So I scan my files with previous versions so that I can revert his changes. But it's a slow and boring process.
Is there another way to do that? Maybe an extension or a script?
The only way to automate that process is through:
subtractive merge or negative merge (as described in this IBM article):
cleartool merge -to filename -delete -ver \main\branch\version_number
cset.pl, which can take all the checkins of an UCM activity and cancel them.
See "Clearcase: how to rollback all changes on specific branch?".
But this is for UCM (which might not be your case)
In both cases, the idea is to create a new version which cancels the version of your other developer.
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.
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.