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.
Related
Is there a ClearCase equivalent to hg shelve (or git stash for those of the other persuasion)? The closest I can think of is doing uncheckouts and saving keep files, but that means I'd have to hunt down the keep files afterwards, re-checkout the files and merge. I realize that ClearCase and Mercurial/Git have different philosophies behind them, but I'd be interested if there is any work in making ClearCase more "usable".
I listed a few for other version control tools, but none for ClearCase.
I explained, for ClearCase UCM, that a shelve command isn't easy to implement.
Instead of just saving the .keep files, you could save patches (unix diff between a .keep and its original version), since a patch can be re-applied later.
The other approach is to modify the config spec (easier when in a non-UCM view) in order to checking the currently modified versions in a new branch (see this config spec)
You can then decide to merge that branch later.
The philosophy is quite different.
In Clearcase, if you need to work on another branch/release, you usually have to use another Clearcase view. If you have Clearcase/UCM, it is even more true as you would use another view attached to another UCM stream. You would not be able to use the same view, whereas in Git, you would be able to stick to the same clone and perform a git stash, git checkout in order to start working on another release.
Now let's assume you need to work on another feature, for the same release. Under Clearcase/UCM, you would be able to create a new activity (cleartool mkact) and work on this new activity, using the same view. All the changes made will then be associated with this new activity. You will also be able to switch back to the previous activity using the command cleartool setact. The tricky part is if you need to deliver the activities separately. This will not necessarily possible as you might need to deliver both at the same time depending on the content of the changeset. This doc about determining dependent UCM activities is quite useful. If you need to move some changeset between activities, you can use the command cleartool chactivity with -fcset and -tcset options.
As a summary, with Clearcase UCM, if it is for different release, switch views and streams. If it is for the same release, play around with the UCM activities, knowing that it is less flexible than git stash.
What is the Clearcase equivalent of git's no fast forward (--no-ff) switch? Or how can I achieve the same functionality?
BACKGROUND
The situation is we are running multiple release branches and we need to be able to pull a feature or defect fix from the release branch if required. Currently (and I'm not the one managing Clearcase) all defect work is checked directly into the release branch, so backing out changes is time-consuming and potentially error-prone.
When using git with --no-ff, I can back out a feature or defect very quickly with minimal chance of causing an issue.
In ClearCase, you would instead cancel an activity (if you are using ClearCase UCM), or cancelling merges for a set of files with negative merges.
But there is no notion of "fast-forward": there is no HEAD to move, only versions (file by file) to merge. So if you know the merged versions, you can create new versions which cancel them (that is what the negative merge does).
There is no ff but there is also no HEAD in clearcase in the sense of git. The workflow is different. You always check in your code to a new checkin (or commit in git terminology). So it is like you are always doing a merge commit
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.
I have a requirement posted by the development team to reverse all changes in a given UCM activity. Constraint being we do not have delete rights. Meaning I know I can do a lsactivity to list all elements in an activity with their respective versions and then in the easy world would be able to delete those versions.
But the SCM policy does not permit us to delete/rmver anything. So I am left with back merging 1 version back. Meaning let us say I have version 5 of a.java checked into an activity. One way I think to achieve this, is find version 4 (using -predecessor) and blind copy this ver 4 as ver 6. Assume that each file has only 1 version in an activity this time. If a file had more than 1 versions checked in through an activity, this would be more complex, so lets ignore that for now.
Any other ideas or whether my approach would/would not work ?
One more robust way would be to:
list all files in an activity
for each file, find the oldest version
make a negative merge, or subtractive merge.
A subtractive merge can be performed to exclude or bypass bad versions on a branch without actually removing the bad versions.
Cleartool merge using the -delete option will allow a user to merge from the last known good version to a new version on the same branch which excludes the work done in the versions identified as bad versions.
That would be compliant with your SCM policies in place.
That is in essence what does the cset.pl script mentioned by Tamir, as I explain in "Clearcase: how to rollback all changes on specific branch?"
ccperl cset.pl -undo myActivity