I have been taught that when you create an activity based baseline the selected activities are baselined and the newest version of all the other files in the vob are baselined. When I baselined the other day I found that this did not happen. Two files had version 2 baselined again, not version 3. Versions 2 and 3 are different.
To create the baseline I use a similar command as:
mkbl -c "This is my comment" -activities Activity#/vobs/46002913/46002913_pvob
-full -view 46002913_ucmview_int BaselineId
Is what I was taught wrong or am I using a malformed command?
One scenario explaining this would be the versions 3 were not visible in the view used to make said baseline.
As mentioned in the mkbl man page:
Before creating the baseline, be sure that the label is unlocked and ordinary (not global) and that labeled elements are checked in. Once the baseline is created, the label cannot be moved or removed except by privileged users.
Be certain the label selects some version of all visible elements.
Either the versions 3 were created just after the baseline (their date can be compared to the one of the baseline), maybe because they were checked-out (in some other view or even in 46002913_ucmview_int view), and checked-in later.
Or they were not visible for some reason (custom config spec)
Related
I'm new to CC and I'm coming from Git and Mercurial background, probably thats why ClearCase confused me so much. I've been assigned a task to migrate latest CC's revisions to Git. Problem is that I couldn't manage to checkout any branch other than main in CC.
I have a view that displays all VOB's /main/LATEST revision. I assume, main branch's latest revision.
element * CHECKEDOUT
element * /main/LATEST
Now I need to get the list of other branches in a particular VOB. To do that, I navigate from terminal in that folder and run
cleartool lstype -kind brtype -invob /%VOB_NAME%
and I can see the list of branches. Correct me if I'm wrong, but I assume, it displays only the branches relevant to VOB(%VOB_NAME%).
Now I need to checkout the branches. What is the standard way of doing this. I tried updating config spec with something like:
element * /%VOB_NAME%/%BRANCH_NAME%/LATEST but it doesn't seem to work.
Pretty sure I'm not doing it correctly.
Also for migration purpose, I'll need to automate the steps to acquire branches and checkout the branches. I guess updating config spec to switch branch in a view takes some time and probably is an async operation, so is there a way to determine when view finishes updating?
Or maybe there's command line option to switch branch for a particular VOB in a view?
So in short, here's my questions I'm struggling with:
Than
Am I acquiring VOB branches correctly?
How can I checkout a particular branch?
Is there a way to determine when checkout finishes?
thanks
UPDATE
ok I tried #VonC's recommendation so my config spec looks like this:
element * CHECKEDOUT
element * .../heine_1/LATEST
element * /main/LATEST
If I'm guessing correctly, one VOB containing branch named heine_1 should checkout that particular branch, the rest of VOBs will stay on main branch, but this is not the case. When I run cleartool ls inside that VOB, its still on main branch. All folders are postfixed with Rule: /main/LATEST. So I guess it didn't switch the branch.
Thanks
There are a few questions in the original question and the comments.
Addressing the configspec issue first...
The syntax of an element rule is:
element {path} {version rule} {optional clauses}
If you need a VOB-specific rule, you can do something like this:
element \myvob\... ...\myvobbranch\LATEST
element \myvob\... \main\LATEST -mkbranch myvobbranch
The "..." in the path means "this location and everything underneath it."
The "..." in the "version rule" means that the branch name is at the end, so this would match /main/myvobbranch/LATEST, /main/br1/myvobbranch/LATEST, etc.
If you're working on a branch, you generally want new files or work to appear on the branch you are working in, and the second line makes that happen.
Everything in a configspec is case sensitive, so be aware that "LATEST" is not "latest."
Since the view was created for you, I'm reasonably certain that it is a dynamic view. If it is mapped to a drive, it's definitely dynamic. If you need to know for sure, you can CD into the "working area" of your view and run "cleartool lsview -pro -full -cview" and look at the "attributes" line. The line for a dynamic view will look like this:
Properties: dynamic readwrite shareable_dos
On the direct questions:
Yes, you are acquiring the branch list correctly.
By default the checkout is done using the version selected by the view, you can use cleartool checkout -branch {full branch path} {file name} to check out the latest on a branch, or cleartool checkout -version {version id} {file name} to check out a version other than the latest on a branch. I would not recommend either as a normal practice. The -branch will cause checkins to go to the element's parent branch. The -version would require add a requirement to perform a merge to get the checkin to complete, which would also go to the version's parent branch.
Checkout is finished when the command finishes.
A big "new user gotcha" is that directories are also versioned objects. If you're adding files to source control, you need to remember to check the directory in so that they are visible by others with similarly configured views. The ClearCase GUIs have this behavior as a default if you started the process with the directory NOT checked out, but not if you explicitly checked out the directory beforehand.
I have checked in some files in a branch but unfortunately I forgot the branch name but I remember my view name to which my branch is associated. I also checked my config spec but the branch which is written in the config spec is not the branch that I want.
Actually I created two branches in a view but one branch name I forgot and as I said in config spec also only one branch name is written. Is there any way where I can list all branches associated with a particular view?
No: only an UCM view has an associated branch (through its stream).
See "How to obtain UCM stream and baseline with cleartool?" or "How to get ClearCase stream name by a given view path?"
cleartool lsstream -fmt "%n" -cview
A non-UCM view would have any selection rules you want in its config spec.
You need to do a cleartool lsvtree /path/to/a/file (add --graph for the graphical view) in order to see its versions and the branches involved.
How to copy an element or file from Clearcase with a particular label, without applying that label in config specs.
I don't want to change the config spec of my view, but I need to access an older version of one of my selected files, and I would like to do so directly from my existing view (again, without changing anything).
I know the version I want to restore (from instance version 2, even though I am selecting currently version 3 in my view).
What cleartool command would you use in order to access said old version?
You can use the extended pathname, but only using a dynamic view (any existing dynamic view, not particular config spec required).
The article "To open a version not currently in your view from a command prompt using a version-extended path" mentions that you can use a snapshot view too, but you would need for:
the element to be already loaded (obviously not at the version you want)
the old version to be copied into the view (as a private file): cleartool get -to prog.old.c prog.c##/main/r1_fix/1
Note that the contextual menu of a version tree includes a "Send To" entry which would effectively do the cleartool get (i.e. the copy) for you.
But in a dynamic view, you don't need to copy anything, you can directly reference any old version:
cp foo.c##/RLS4.3
cp include.h##/main/bugfix/REL2
See also version selector:
If a version label was defined to be one-per-element, an additional link/file system object appears at the top level of an element's directory tree.
For example, if BL3 is a one-per-element label, these version-extended pathnames are both unambiguous references to the same version:
hello.c##/BL3
hello.c##/main/bugfix/patch2/BL3
In effect, this feature allows you to reference a version without knowing its exact location in the version tree.
In a dynamic view, when you see hello.c in your view (and that can be any selected version, not the one you want with the label), you actually can do:
cd hello.c##
dir
That will list all the unique labels for you to choose from.
Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)
"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a snapshot view
change the read/write right (at the OS level, nothing to do with ClearCase here)
modify them directly (without checkout them first, hence the "hijacked" state)
The OP Kevin Little adds in the comment:
Alas, we only use dynamic views
Easy enough:
"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a dynamic view
copy the files you need to modify as aFile.tmp
modify the config spec to not select them
copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
remove the "none" selection rules from the config spec
modify them directly
To not select them, add to the config spec (ct edcs) before the other rules:
element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...
To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.
I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.
We have a patch model where we're intending on using cset.pl -findmerge <activity> to selectively merge cumulative activities to a patch stream (integration stream to integration stream). Note that we're using a single stream model; although support for teams working with their own dev stream would be supported (i.e. when they join a project they would be working with the integration by default).
However there's the issue of activity dependencies we're trying to solve.
So say you have integration stream A,
file a.txt
-> Change 1 (baselined ReleaseA)-> Change 2 -> Change 3
fileb.txt
-> Change 1 (baselined ReleaseA)-> Change 2
an integration stream B and the config. manager decides they want to include "Change 3" in a new patch (patch integration stream - integration stream C).
They perform a cset.pl fetchmerge against Change 3 (which includes changes for Change 2).
Change 2 for fileb does not get picked up so the issue is identifying these activity dependencies.
Anyone have any ideas?
If Change3 is a rebase/deliver activity you can use
%ct lsact -contrib Change3
to get a list of contributing activities
and then traverse any of the rebase/deliver activites listed as contributing
activities to trace if any of them has Change2 as the contributing activity.
Also assuming that the foundation baseline for the patch stream is the one used for RelaseA,shouldn't you need to list activities from Change1 onwards when you do the merge ?
i.e shouldn't your findmerge invocation be something like
%findmerge ... Change2,Change3 -fcsets ...
Note (in addition to sateesh's answer), a deliver -act Chaange3 (instead of a findmerge) would list Change2 and Change1 as activities to include in your deliver.
It would pick up on those dependent activities, probably following an algorithm close to the one described by sateesh.
See "About activity dependencies in the deliver operation"
alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/deliver_depnd.gif
Had to use a variety of cctool commands to view current version in view and pushed it into a script to get a list of activity dependencies