Applying label error
cleartool: Error: label type "label_1" not found in VOB "\newvob" and no global type definition can be found.
cleartool: Error: Unable to create label "label_1" on "newvob" version "\main\12".
This IBM technote mentions:
cleartool relocate aborts with the below error when attempting to move a single element, foo.c, from a source VOB, vob1, to a newly created target VOB, vob2.
But if you weren't relocating a file, then it can be an hyperlink issue between ClearCase and ClearQuest.
Or (if you aren't using the integration with ClearQuest): a broken hyperlink with the Administrative pvob.
Check that last link first: it is probably the most common cause for this error message.
AdminVOB and its corresponding client VOBs are linked together using hyperlinks.
Note: A hyperlink also exists on the local copy of the global types residing in both VOBs.
Each VOB can only have a single AdminVOB.
An AdminVOB can be linked to another AdminVOB.
Step by step under the hood:
ClearCase looks in the current VOB for a local branch type definition (either a local type, or a local copy of a global type).
If it exists:
The client checks the parent global type for "process guards" (currently only used for UCM stream associations, but this check is made against all branch, label, an other types for backward compatibility reasons).
If no "process guards" are found, or those guards allow the branch to be created (checkout in UCM branch type in view connected to the right stream), the client creates the branch from the existing local type.
If a local copy does not exist, the client will look for an AdminVOB hyperlink.
If the AdminVOB hyperlink exists and points to an existing VOB:
the client searches that for a global type definition with the same name as the branch being requested.
If the global type exists, it will be examined for "process guards" as described above, if not, you will see the error in step 5 below.
If no "process guards" block the mkbranch operation, then a local copy of the global type will be made in the VOB where the mkbranch operation was requested and the requested branch will be created.
If no AdminVOB hyperlink exists, the client reports the following error:
cleartool: Error: branch type "{name}" not found in VOB "\mkvobtest" and no global type definition can be found.
cleartool: Error: Unable to create branch "{name}" from "." version "{parent version ID}".
Related
I have a specific file that should be rebuilt on each compilation regardless if it has been modified or not. The reason is that it is depending on system macros whose values change. How could I force rebuild with CMake? I'd like to not bind it to specific target: the file should be "touched" before any of the targets specified in CMakeLists.txt begins the actual build process.
CMake has a add_custom_target command:
Adds a target with the given name that executes the given commands. The target has no output file and is always considered out of date even if the commands try to create a file with the name of the target. [...] By default nothing depends on the custom target. Use the add_dependencies() command to add dependencies to or from other targets.
I am trying to build a Github repository(https://github.com/rougier/freetype-gl) using cmake. The below error shows up:
expected identifier or '(' before '.' token ../texture-atlas.c
Background: The folder contains a file called texture-atlas.c which has just this one line:
../texture-atlas.c
There is also a file by the same name in the parent directory which is being referred. How do I go about fixing this error?
That file is supposed to be symbol link, pointing at the file ../texture-atlas.c (i.e. this file).
In Linux, symbolic links are represented as text files containing the path to the link target, and a special meta-info flag in the file system that says "this is a symbolic link". That's why you get the target file name as the contents of the file, that's all that remains when the link flag doesn't exist.
You probably cloned the repo on a platform not supporting symbolic links. Try copying the file over the link.
Edit:
The installation instructions for Windows say:
Note: Harfbuzz examples only work with symbolic links enabled. See https://github.com/git-for-windows/git/wiki/Symbolic-links.
So you should probably follow that link, and see what to do.
"cleartool lock" command can be applied to lbtype object "REL1" as well as "file element foo.c version \main\3".
Assume REL1 has been applied to foo.c##\main\3.
Assume foo.c##\main\2 is unlocked.
Applying lock to lbtype object "REL1" will prevent applying "REL1" to any more versions of any other files.
This will not prevent replacing "REL1" on an foo.c version \main\3 with another yet unlocked LABEL TYPE "REL2" for example.
This will prevent relocating "REL1" to foo.c##\main\2 assuming foo.c##\main\2 is unlocked.
Applying lock to "foo.c##\main\3" will prevent removing the already applied RELEASE LABEL type to that particular version to be replaced or to add any more new LABEL TYPE to that foo.c##\main\3 of the element or removing any already applied Release Label Types to foo.c##\main\3.
Applying lock to an element version doesn't prevent checkout for the element version.
Are all the above statements correct, so that I understand difference locking Release Label Types and File Element Versions?
cleartool lock
Applying lock to lbtype object "REL1" will prevent applying "REL1" to any more versions of any other files.
yes:
Label type. If a label type is locked, you cannot do the following:
Use the type in an rmtype, rename, or mklbtype –replace command
Attach or remove a version label of that type with mklabel or rmlabel (This includes moving a label from one version to another with mklabel –replace.)
This will not prevent replacing "REL1" on an foo.c version \main\3 with another yet unlocked LABEL TYPE "REL2" for example.
Not exactly "replacing": you can add many different labels on a given version.
This will prevent relocating "REL1" to foo.c##\main\2 assuming foo.c##\main\2 is unlocked.
Yes:
Version Lock:
If a version is locked, you cannot do the following:
Attach a label using mklabel
Remove a label using rmlabel or mklabel -replace
Attach an attribute using mkattr
Remove an attribute using rmattr or mkattr -replace
Remove the version using rmver
/vobs/trms/NVaR/DSR/simulationEngine/common##/main/2/nVARUTL.cxx##/main/nz_mig/1
Can someone explain the meaning of the above line?
Jim
This is an extended pathname which references:
the version 1 of nVARUTL.cxx in branch main/nz_mig,
itself accessible in the version 2 of the folder common in branch main
See more at "pathnames_ccase".
The ## references the element (common or nVARUTL.cxx), followed by their versions (branches/version).
element-pname##version-selector
Since the path starts with /vobs, it means you are accessing that version through a view set (cleartool setview) on Unix.
See as an example "About the version-extended path"
Note that each elements are selected by their own versions.
So your config spec shows only the versions of nVARUTL.cxx: /main/nz_mig/1, with branch nz_mig coming from main/14:
This has nothing to do with the version of the parent folder common.
That parent folder 'common' is selected by the version /main/2.
If a file A is not symbolic link, we can use describe to get the labels which were applied on its current version.
But if it is symbolic link, we can just use describe to get a relative path of the target file. Is there any easy way to list the labels of the target of a symbolic link?
No, for the same reason you cannot access their extended pathname:
Symbolic links are not versioned and, hence, do not have version-extended pathnames.
Symlinks are not catalogued in the version history of the element. They serve only as a pointer to a target version, and allow you to create multiple access points to a single version.
You must first resolve the link element destination in your current view configuration before listing the label on that destination element (file or directory).