In CCRC we have a "MainBranch" from main Branch we took a branch named "branch1" with label "label1" and we started checking into that.
The main branch also having a label with the same label name "label1".So we created another label "label2" in the same branch "branch1" and checked in some code into that.
Is it possible to rename "label1" to "label2" in branch1 without affecting the codes in "mainBranch" ? so that we will get the entire codes under same label. If any other way to solve this issue please suggest
A label references a collection of ClearCase versions (files and directories), and is used in a (CCRC web view) config spec (like this one) to start a branch.
It should be immutable (meaning the content it references should never change)
So you cannot renaming an existing label without affecting an existing views, with version created in branch1 from label1 which would no longer be visible/accessible after renaming the label label2.
Simply keep working in branch1 as it is defined, or merge branch1 in MainBranch, then create a new label and a new branch from there.
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 created a symbolic link for folder1 to make it available in vob2\rootdir from vob1\rootdir.
And I labeled the whole directory folder1 recursively in vob1.
But when I modified the configspec of dynamic view to load folder1, it was loaded under vob1; But I couldn't see that folder in vob2\rootdir. Pls help.
First you don't modify a config spec to load anything in a dynamic view: you only modify selection rules, there is no load rules (as opposed to snapshot view).
If you were actually using a snapshot view (with a path different from M:\ or /views), then beware of symlink resolution issue like this one.
Finally, if your config spec doesn't select vob2/rootdir, or if it doesn't select the version which recorded the symlink, you wouldn't be able to see said symlink.
That means, labelling vob1/folder1 isn't enough: you need to make sure that:
/vob2 is labelled
/vobs2/rootdir is labelled as well
In other words, the parent folders of your final selection target (target being '/vobs/rootdir/folder1) must be selected.
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.
Within 'Pending Changes' RTC source control is listing my target folder as an outgoing change. My project is maven based. I have not made any changes to the target folder.
When I compare the target folder with the stream I am flowing to I there are no differences displayed :
Is there some other criteria that is causing the 'Pending Changes' view to list my target folder & how can I determine what change is being recognized by RTC ?
When I try and undo the changeset within the target folder I receive the error :
The little + in the black arrow above the 'target' directory means RTC detects said directory as a new element to be delivered.
That means you must have checked in that directory with the rest of your changes.
Generally, target should be ignored (ie never considered to be checked-in in the first place).
In your case, you should:
remove that directory from your changeset (assuming you didn't already complete the changeset): try undo on the target directory within your changeset.
(That would actually trigger, for a newly created element, the error message
"Undoing this change would produce an orphan with no parent folder").
Right-click and select "ignore"
(don't select "Reverse" on the changeset itself: it would roll back all the changes currently checked-in)
add it to your .jazzignore: the ignore option will add or create a .jazzignore, in order to declare your directory in it.
Of edit your .jazzignore if you have already one, with a content like:
core.ignore.recursive= \
{target}
Note: with ClearCase, the issue is different, since ClearCase doesn't detected what is private from what is checked-out (and you don't check out with RTC).
You need to ask explicitly for all private files or all checked out files.
Good morning,
is there any way to exclude only one particular directory from a snapshot's load statement, e.g. I want to load a whole vob named 'PM_CT' except the \PM_CT\lost+found directory
... is there an elegant way to do it? And how would I generally exclude all lost+found directories across multiple loaded vobs?
Cheers and Thanks,
-Jörg
I would like to make an addition to the previously posted answer:
The lost+found directories
To exclude the lost+found directories across all VOBs you can modify the previously proposed selection rule to be more generic:
#Skip the lost+found directories
element .../lost+found -none
However, using the '-none' flag causes the Windows ClearCase client to list errors when updating a snapshot view:
Unable to load "lost+found": no version selected in configuration specification.
Unable to load "lost+found".
It also does not properly unload any previously loaded folders or files, so you may need to recreate your snapshot view (or unload/reload the VOB) with the new selection rule if you really want to clean out the lost+found directories...
Elegance
For excluding any normal folder, the "elegant way" would be to specifically load the /main/0 version of the folder:
#Exclude the contents of a directory
element /VOB_name/folder_path /main/0
This will cause the folder to be loaded as empty and will not produce an error. It will also properly unload any loaded files. It unfortunately does not work for the lost+found directory, because it is always listed as version /main/0.
element /PM_CT/lost+found -none
The "elegant" way consists of:
adding a selection rule (here "-none")
loading all PM_CT without aking any question (load /PM_CT), if your view is a snapshot one
Note: in a config spec, always use "/": it is easier, and Windows as well as Unix ClearCase views will be able to interpret it.
Caveats:
the previous solution is for one vob, I do not think you could use "wildcard" for multiple vobs
the '-none' option can cause a snapshot view to fail during a deliver or rebase (UCM merge): for that kind of operation, a dynamic view would be more suited. That is for CC 2003.06 and early 7.0. I think it works better with the latest CC7.1.0.2
Note: that selection rule can also be used for dynamic views, in order to mask some directory you would not want to see.