Is there a way I can create a view that will give me a snapshot of all the files modified in a specific ClearCase branch?
For example, say I have two branches:
product_1.0_dev
product_migration_1.0_dev
The second branch is conceived as a testing ground for upgrading our core framework dependencies. I know that if I modify a file in product_migration_1.0_dev, then I will have a \1 version under this branch, so there has to be a way to write a load rule to get this info easily into a snapshot.
Any ideas?
That would be a selection rule (not a load rule)
element * .../product_migration_1.0_dev/LATEST
element * .../product_1.0_dev/LATEST
element * /main/LATEST
Note the '...' notation (see version selector), an ellipsis wildcard which allows to select a branch at any branch level.
Note that would list all files, including the ones you want.
If you want to see only the files for a particular branch, you still need to select their parent directories: and those might not have a version in the product_migration_1.0_dev branch.
So the following config spec (that I invite you to test in a dynamic view first: it is quicker, then you will report that config spec in a snapshot view, with its own load rules) would be more precise:
element * .../product_migration_1.0_dev/LATEST
element -directory * .../product_1.0_dev/LATEST
element -directory * /main/LATEST
So you would select files and directories having a LATEST in product_migration_1.0_dev branch.
Otherwise, you select directories only in product_1.0_dev branch or in main branch.
That way, you are sure to select the parent directory of an element which might have a version in product_migration_1.0_dev branch.
If you don't do that, your view won't ever be able to select the files, because their parent directories are not accessible (none of their versions is selected from which a product_migration_1.0_dev branch starts).
Related
I'm having a ClearCase read-only branch A.
I want to create an exact copy/replica of Branch A and create another Branch B.
Can we make such an exact replica of branch A at byte level?
Is this possible?
Update:
As suggested by #VonC, I tried to make a change in the Branch A, let's call it "A_read" and it gave me an error in the checkout. Sorry had to paint some info as per company policy.
You simply create a viewB which starts at a label A you have set in viewA.
Or you start from A/LATEST:
That viewB will have a selection rule like:
element .../A/LATEST -mkbranch B
# or
element * A -mkbranch B
element * /main/LATEST
That means:
it select the latest version in branch A (.../A because A can derive from /main or /main/someOtherBranch, or /main/X/Y/...)
it will create branch B only if there is a checkout.
A branch in ClearCase has a starting point, and will have version of its own only once changes are versioned (checkout/checkin).
Right now, with that selection rule, branch B is identical to A, in that it starts from the versions selected by A.
Can someone guide me to deal with this in the right and best way? I have two active dev branches where-in the same code base is being modified and one integration branch in a base clearcase environment. But i wanted to prevent code promotion from branch 2 to integration branch and allow merge only from branch 1 to integration branch. Please advise.
If there are different users delivering from dev streams to integration streams, you could (using cleartool lock -nusers ... stream:aStream#\vobs\apvob):
lock devstream1 for all except dev1 (that way you are sure dev1 can only work on devstream1),
lock devstream2 for all except dev2 (that way you are sure dev2 can only work on devstream2),
lock intstream for all except you and dev1 (that way only dev1 can deliver to intstream)
What if I or dev1 mistakenly promoted code from devstream2 to intstream
Then you would need a preop deliver_start trigger (with mktrtype).
That trigger would control the OIDs of the streams in the trigger since these are immutable: cleartool describe -fmt %On <stream-name>
If one of them is the one for devstream2, the trigger would exit in error, denying the deliver.
Since it sounds like your using Base ClearCase, you can use a preop 'checkin' trigger. The script the trigger executes would look to see if the checked out version about to be checked in has any incoming Merge hyperlink(s). If it does, the script can verify that the "from" end of the hyperlink is coming from branch1 and exit with a 0 status if so. If it's coming from any other branch, the script will print a descriptive error message and exit with a non-zero status (thus preventing the checkin).
When creating the trigger type, you can limit the scope of the trigger to the integration branch (which I'll call 'my_int_branch' in the example below) which helps with performance. The command line might look something like this:
% cleartool mktrtype -element -all -preop checkin -brtype my_int_branch -exec path_to_allow_branch1_merge_script allow_branch1_merge
In the script, you can get the Merge hyperlink(s) attached to the checked out version with something like:
cleartool describe -fmt '%[hlink:Merge]p\n' $CLEARCASE_PN
If there are any incoming Merge hyperlinks, you'll get one line per hyperlink looking something like this:
"Merge#2877#/vobs/myvob" <- "/vobs/myvob/mydir/file.c##/main/branch1/3"
The script then just has to verify that the outer branch of the "from" version is "branch1".
Running CC 8.0.0.3 w/UCM and ClearQuest enabled.
We have a build system which is supposed to run mkbl -view after a successful build in the integration stream. Normally this completes in a few seconds after each build. That works fine, but it turns out one build job omitted the mkbl command.
I am trying to retroactively apply the mkbl command for those. I need to do this 4x to come up to date.
BL label - #activities - # element versions
1.2.6 - 57 - 513
1.2.7 - 16 - 107
1.3.0 - 26 - 159
1.4.0 - 60 - 460
I have attempted the command:
cleartool mkbl -view my_view -act ${ACT_LIST} -inc -c "${LABEL}" ${LABEL}
where ACT_LIST is the list of activities (activity#/mypvob), since the prior baseline, LABEL is my label
It's been running over 12 hours and still has not even come back indicating creating baseline.
Am I doing this wrong? Is it just slow? Is it possible to retroactively apply a baseline?
Thanks.
First, it would be quicker for your first non-missing baseline is promoted to "full" instead of incremental: the delta (of files or activities) between two baselines would be quicker to compute.
You can keep creating incremental baselines on top of that full one.
Then you can start testing making a baseline with just one activity and see if that complete: making multiple baselines with the same label will lead to multiple baselines with different ID (same title).
Is it possible to retroactively apply a baseline?
Baselines are created sequentially on the stream: they cannot be "inserted".
If you already started to put new baselines on that stream (after missing a couple), you cannot try and create ones before.
But the OP mentions:
No, there were no subsequent baselines and the first baseline's list of activities goes back to the last actual baseline.
Since mkbl fails (too long), I would:
change the config spec of the UCM view in order to select files before a certain date (add a time-based selection rule at the start of its config spec)
put a label on all files of the component (mklbtype+mklabel)
import that non-UCM label as a baseline (mkbl -import)
See if you can create your baselines that way.
The OP Ian W concludes in the comments:
neither incremental nor full worked.
I tried mkbl -import, but then I could not recommend and use as a future baseline, so I gave up.
I had the 4 baseline equivalents all labelled, then made a full of the latest, which worked and should keep me moving forward
In a major development, I have added multiple files to the source control into my private branch. There were also existing files that was modified and checked into my private branch. Now as we are approaching to merge the changes to our project branch, I would like to validate all the elements I have newly added to my private branch, to ascertain if the locations are correct (ex, they should have been placed in another location and a symlink should have been added)
I listed all the elements in my private branch, but could not figure out, which of these elements were newly added.
Is there a reliable way to do so?
You can do a query finding all elements in a given branch since a certain date for a certain user:
cleartool find . -type f -branch "brtype(abranch)" -element "{created_since(10-Jan)}" -user aloginname -print
(this would search only files, as mentioned in "how to find files in a given branch", and also in "how can I list a certain user's activity in a branch")
The other approach is to create a dedicated (simple base ClearCase) view to display those elements, as in "Get all versions from a specific time" or in "how to find out all the activities happend in a branch in the last month?".
But generally, the first query is enough.
I have to merge all objects from a sub branch to main branch recursively. I would like to merge manually by check in the code from sub branch to main branch instead of using merge command in clear case.
So after the check in into the main branch I would like to draw arrow
recursively to all my objects.
ic from sub branch to main branch
I have used this command
cleartool mkhlink -unidir Merge <sub branch path>>##/main/<<sub branch>> <<main brach path>>##/main/LATEST
But when I dit it, it is drawing the arrow for the directory only not for all contains of the directory.
Please suggest how to draw the arrow recursively from sub branch to main branch objects.
Thanks in advance
According to the merge man page,
cleartool merge -ndata -to aFile -version /main/a/SourceVersion /main/a/DestVersion
will draw a red arrow without performing any actual merges.
Since you have made your checkout/checkings in a branch or a UCM activity, what you need to do is:
be in your destination view (the one where the merge occurred)
query all the versions you made for that merge
extract the file for each version
extract the destination version
compute the source version (for instance /main/aBranch/LATEST)
do a "merge -ndata"
So, it is not so much a "recursive" algorithm, but rather an enumeration of all versions involved in this merge in order to draw the appropriate red arrows.
Just use the ClearCase Merge Manager - it should take all the pain out of doing a task like this.
I know this is 8 months later but have you tried this?
cleartool find . -type f -nxname -exec 'cleartool merge -to $CLEARCASE_PN -ndata -version /main/aBranch/LATEST '
Probably do not need the -nxname in the first part. I changed to the directory that I wanted to create only merge arrows to and did a FIND for everything in the directory.