We use ClearCase UCM which has multiple Vobs (10).
How to find the activities for past one week?
Or list activities between two date ranges?
It is a bit trickey, because all cleartool lsactivity commands are limited to one pvob ("project vob" or "special vob with UCM metadata in it"):
cleartool lsact -invob \my\pvob -stream ...
And an activity can be reused (meaning an old activity can have in its changeset very recent versions)
If you have two baselines, you can easily diff them (by activity): See ..diffbl**.
ct diffbl -act baseline:bas1#\myPVob baseline:bas2#\myPVob
(that is necessary for one component within one Vob though)
But if not, you need to list all activities and their changeset, to see which one contains version produced in the relevant date range.
We are using a ClearCase UCM plugin which called "Compare BL", made by "Go Midjets". It answers your needs.
Here a useful snippet for Linux tcsh.
For each activity you get you may want to list its changed set.
You can use
cleartool lsact -s and cleartool lsact -fmt "%[versions]p" <act_Name>
as shown here:
http://www.snip2code.com/Snippet/961/list-files-changed-in-clearcase-ucm-stre?fromPage=1
Related
I have a very basic question in clearcase.
does every version of an file have same OID? As far as I know each version is an object and each object will have a different OID.
I even checked with cleartool dump and each version has different OID.
More precisely, as explained in "How to find oid and uuid of an element in IBM Rational ClearCase"
Every single object in a ClearCase VOB is referenced by its oid ("object ID").
The oid is unique inside the VOB.
This does not apply only to file, but to all objects in the VOB.
Element
Version
Metadata
ClearCase uses the oid internally. The oid is invisible for common user's operation. However, in some error messages, you see a reference to an oid.
To find the oid from an object, you use :
cleartool dump <object>
To find the object from an oid, you use :
cleartool dump oid:<object>
For theses commands to work, you need to be in a view and in the corresponding VOB. This is necessary in order to generate the path/file name.
<object> can be anything defined as an object for ClearCase. Like for instance:
element <file>##
version <file> or <file>##\main\......
type lbtype:<name>
VOB or replica object vob:<vobtag>
You can also run "cleartool describe -long oid:<oid>" on the oid while set in a view to the root of the VOB to which the element resides, and the output will return an element name.
See "Identifying elements by the source container path"
So I have a branch is that is dreadfully out of date with the rest of the world. I'd love to simply create a new branch and merge over... but that task would be even larger... anyways what I'm trying to figure out is if I can set findmerge to always accept file 2. To speed my merge up, I initially did:
cleartool findmerge <path to out of date code> -ftag <my merge from view> -merge -abort
to cover all the simple merges, but not I want to grab the 'conflicting' changes, but I really just want all changes from from 'file 2'.
Is there an easy way or flag to provide to findmerge to do that?
Or do I have to go file by file and choose each change individually?
At the end of the day, I want what is an branch that has for a specified folder what is exactly in the merge from area.
I'm guessing the answer is 'no' but I have hope, and my figures are getting tired of pressing the return key :-)
For that kind of "reset" merge, where you want one branch content to (after merge) mirror the content of the source of that merge (2), I don't use findmerge at all.
I set an activity (if I am on UCM), and I initiate a clearfsimport in order to import data from the source view to the destination view.
I then create merge arrows between any visible version of the source view and their matching element in the destination view (as in "how to ignore files when finishing private ClearCase branch?", or "Merge arrow in ClearCase" -- that is the red merge arrow --, also used in "How to perform a trivial merge of a binary file in a ClearCase VOB")
cleartool merge -ndata -to aFile -version /main/a/SourceVersion /main/a/DestVersion
That way, one source branch has been merged to the destination, and the source content has been copied over the destination view content.
This should in theory be quite simple, i.e. merge the changes from a specific UCM activity from one stream to another.
I had thought that I might just be able to use the Deliver command in the GUI and then select just the required activity to deliver, but it seems that the target stream is set to not allow deliveries from other streams.
From searching the documentation it seems that I might instead be able to do this via the command line using the findmerge tool, but it's not at all clear from the rather sparse documentation how you do this. It seems like it might be a two stage process, i.e. first generate a "changeset", then merge that changeset ? Also I'd like to do the merge manually for each affected file, so I would need the graphical merge tool to be invoked if possible.
If someone can give me an example findmerge + whatever command line for merging an activity that would be a great start. Also any other suggestions for how to merge an activity would be welcome.
First, deliver in UCM are (usually) made to deliver all activities.
You can try to deliver only a subset, but you quickly comes to gripe with "timeline", which are linked artificially all the activities together, forcing you at the next deliver to deliver them (all).
findmerge tool, but it's not at all clear from the rather sparse documentation how you do this. It seems like it might be a two stage process, i.e. first generate a "changeset" then merge that changeset ?
cleartool findmerge activity: is the non-UCM way to merge all versions referenced by an activity from a stream (a branch actually here) to another branch.
ct findmerge activity:A1#\pvob activity:A3#\pvob -fcsets -c "report for delivery" -merge -gmerge
See "ClearCase : Making new baseline with old baseline activities" for more on timeline (activity dependencies) and findmerge.
This is documented in the technote swg21267316:
WORKAROUND:
From the target view:
Set to an activity (setact) or create a new activity (mkact). This activity is just like the Integration activity normally used/created during a deliver. It allows you to:
check the files in after the merge.
Run a findmerge using the following format:
cleartool findmerge activity-selector ... -fcsets [-gmerge | -merge]
Merge files as needed
Checkin files that were merged
Example:
M:\int\cvob1>cleartool findmerge activity:A#\pvob -fcsets -gmerge
Needs Merge "M:\int\cvob1\old folder\new name" [to \main\int\7 from \main\int\de
v\2 base \main\int\dev\1]
Checkout comments for this and any additional elements:
deliver dependencies work around
.
Checked out "M:\int\cvob1\old folder\new name" from version "\main\int\7".
Attached activities:
activity:int-merge#\pvob "int-merge"
How to get only latest versions from latest baseline -
For example, First time in ClearCase, developers check in for the first time, we would have a.zip, b.zip ; ClearCase does the incremental baseline baseline_1. Then the build tool comes in, does it gets artifact..and deploy it - everything looks good.
Second time in ClearCase, they check in c.zip and d.zip ; ClearCase does an incremental baseline again baseline_2... now how can I get the ClearCase snapshot view to only present the new files (c.zip and d.zip) so the buil tool can only get the latest files (or last baseline)
This will go on and on and on.. so baseline will change each time.. so would the file.... and the date will not work since we don;t know the schedule or cycle. The files name can also change from *.zip to whatever...
A baseline references all the files of a component, even if it is incremental.
Using an incremental baseline in a non-UCM snapshot view wouldn't work, because it applies a label only on the elements which are changing (which means the parent directories might not have that label, because they haven't changed, which results in a config spec incapable of selecting the changed files, since said parent directory isn't even selected).
If you are after a view able to show all the latest files, what you can do is:
a sub-stream ST to stream S which produce those baselines
a rebase of ST with the latest baseline from S:
cleartool lsbl -fmt "%[latest_bls]p" -component C -stream S
a diffbl with the previous baseline, in order to get all the new versions
But you also can:
list only the changed/new files:
cleartool diffbl -pred -ver latestBl#\aPVob
access those files through a dynamic view with the extended pathnames returned by the diffbl -pred -ver command.
That would allow to list/access only the new/changed versions between 'latestBl' and its previous baseline (with latestBl obtained from the lsbl command shown above).
I used rcleartool with no problem until yesterday.
In today, "write" commands fail with permission error. I do not change any configuration. I don't know whether CM server changed or not.
some examples when I encounter problem
cmd> rcleartool mkelem -nc {file path}
(some output)
ClearCase CM Server: Error: Can't create object with group (XXXX\Domain Users)
that is not in the VOB's group list.
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.cloneFor(StpExceptionImpl.java:956)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.cloneFor(StpExceptionImpl.java:980)
at com.ibm.rational.stp.client.internal.cc.WebViewBulkOpBase$ReadPropsIterWrapper.checkForBulkOpFailure(WebViewBulkOpBase.java:119)
at com.ibm.rational.stp.client.internal.cc.WebViewBulkOpBase$ReadPropsIterWrapper.next(WebViewBulkOpBase.java:81)
at com.ibm.rational.stp.client.internal.cc.WebViewBulkOpBase$ReadPropsIterWrapper.next(WebViewBulkOpBase.java:52)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doCcVersionControl(CcFileImpl.java:280)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doVersionControl(CcFileImpl.java:269)
at com.ibm.rational.ccrc.cli.command.MkElemCommand.execute(Unknown Source)
at com.ibm.rational.ccrc.cli.command.Command.run(Unknown Source)
at com.ibm.rational.ccrc.cli.command.ClearWan.main(Unknown Source)
(command)
cmd> rcleartool rmelem -f {file path}
(some output)
Request failed in method CcRpc::destroy with status 1001
(file=\nucor\server\stp\ccrpc\ccrpc.cxx, line=1751)'
CRVAP0239E: CRVSV0078E RPC:
CRVSV0841E 'CRVSV0613E Destroy failed: ''error detected by
ClearCase subsystemClearCase CM Server:
Error: No permission to perform operation "remove element".
ClearCase CM Server: Error: Must be one of: element owner, VOB owner, member of ClearCase group
This is usually:
because the current DOS session for this rcleartool command doesn't have the right CLEARCASE_PRIMARY_GROUP fixed anymore
or because of some permission issue on the parent directory where this add to source control (mkelem) takes place.
I would seriously check the first possibility, as it fits the Primary Group requirements for element creation and is found in other cleartool commands like multitool.
Note about mkelem:
The mkelem command has different Primary Group requirements on Windows and UNIX/Linux.
UNIX/Linux:
In order to create an element in a VOB, your Primary Group must match a group in the VOB's group list.
WINDOWS:
As long as you "are a member of" a group in the VOB's group list and the parent directory where the element will be created is owned by the group to which you are a member, you will be able to create elements in the VOB.
If, however, you are a member of more than one of the VOB's groups, the CLEARCASE_PRIMARY_GROUP will need to be set to one of these.
See technote 1135509 for more information about the CLEARCASE_PRIMARY_GROUP variable.
user972301 refers in the comments to "Primary Group requirements for element creation"
I get the same error with cleartool but under Linux when I try to do an mkelem in a snapshot view of a child development stream whose parent is located on a different PVOB than what I usually work wit
One needs to change his local machine's group ownership to match the PVOB's