Is that possible to distinguish if merge was performed manually or automatically?
I'm using ClearCase 7.1.2 on Windows, and I'd like to know if you can find it by watching the version tree or by any given command-line
Thank you
If by automatically, you mean: is a version created by a deliver/rebase, as opposed to a version created by a manual merge, then the name of the activity associated with that version can help:
If it starts with 'deliver' or 'rebase', it is made by a deliver/rebase UCM operation (which automatically merge all changed files from one Stream to another)
But if by "automatic vs. manual" you mean a version merged manually because there was a conflict between the source and destination version (and ClearCase couldn't automatically merge the two), then no.
The result of a merge is a new version with a "red arrow" between the source and the destination, without any indication as to how that new (merged) version was created.
Related
I need some help on how to collect all information from ClearCase and tar or zip it, and store it in a provided space. we have migrated major baselines from ClearCase to different SCM tool .But we still have ClearCase. we want to capture all version, change, baseline, etc (basically capture everything but not the SCM tool itself) and zip it or put it in a flat file or so. this is just for historical purposes, so that tomorrow if someone wants to know what was in the ClearCase then they can see. so ,is there any idea?
The reason this doesn't exist (as far as I know) is in the nature of ClearCase (compared to a revision-based VCS tools).
It is a file-based VCS:
You create a new version for each file you change (instead of a unique repository-wide revision)
You create a label on each file you want to label (instead of a tag referring to a revision or a commit)
You create a branch for each file modified in that branch (instead of a single directory for SVN, or branch for other VCS)
...
That means you wouldn't simply export revisions/labels/branches with ClearCase. You would export them for each file: it doesn't scale well and would take too much time and space.
Migrating major baselines is sensible course of action that I have recommended before.
But for the rest, I always put a ClearCase instance as a way to explore the full history/events in case in is needed, while the recent history is managed in the new VCS tool.
Storing that as a flat file you could read without ClearCase isn't, again as far as I know, available.
Hence my previous "vobstore-reformatvob" proposition.
Recently i was asked to deliver interproject delivery.
While delivering lot of merge request was popped for even binaries.
I skipped them and did draw merge arrow one by one. It was nerve breaking work.
Is there any way to exclude binaries from being merged or some command line option to draw merge for all the binaries?
( I am using clearcase UCM)
Yes, you can change their type manager to a type with the option "copy on merge" (or never merge, if you really don't want them merged at all).
That type manager inherit from compressed_file, but would resolve any merge by copying the source version over the checked out destination version.
See Clearcase UCM is trying to merge pdf files as an example.
You also have the IBM technote: "Handling binary files in ClearCase".
So you have the choice between:
or:
I baselined a stream this morning, but someone made changes to a couple files that they did not want included in the baseline.
I used the Version Tree to move the label from the newest version to the previous version. (First, was this wrong?)
I then delivered that baseline to a stream in another project. It works fine, and all the correct versions of the files came over. However, now the file in view is version 22, and there is a version 23 that I am not able to see. (I would like to see the newer version, even though I did not want that included in the baseline.) Is there a way to make the view show the latest version of the file?
Note: I tried making a new baseline, but ClearCase included version 22 in the baseline instead of version 23...
The correct course of action, when a Baseline doesn't reference the right content, is:
to fix that content (delete as in "cleartool rmname" the files you don't want to see, checkout/checkin the files you want to fix, creating new versions)
make a new baseline (you can take the same name, or 'title': ClearCase will generate a different baseline id based on that name: BLNAME.xxxx: see "What is the difference between Full baseline and Incremental baseline in Clearcase UCM?")
Moving a label is not a recommended solution (it is actually supposed to be impossible if that label is linked to a Baseline)
You then deliver that new baseline to any other Stream you want.
But if the source Stream has some new version, then you will need to make another baseline including said new version, and deliver that new baseline, in order for your destination project to see and reference it.
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