/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.
Related
When we start working on a new release we usually put a new label, for example REL2, on all elements with label REL1. This means that in the beginning of developing a new release, these two versions are identical. As the development progress and elements are checked in, REL2 will be moved to a newer version.
At the end of the development, REL2 can differ a lot from REL1.
My question is, how do I get all elements where REL2 are not the same version as REL1?
You would need to look for visible versions which have the REL2 label but not the REL1 label.
cleartool find . -cview -version "{!lbtype(REL1) && lbtype(REL2)} -print
See more examples at "Additional examples of the cleartool find command".
On this example, how are merges back to “main” from “windows” and “test” branches normally handled (red lines)?
For instance, developer under “windows” branch fixes a bug by setting A=1, and then tests the fix under “windows” and calls it “done”, so he merges “windows” back to “main” as “main/8” that’s not a problem thus far.
But then, say that developer under “test” branch changes A to “A=0” to fix the bug he is working on.
What happens when “test/4” is merged back to “main”?
Now “main/9” shows “A=0”, overwriting the fix done by “windows/1”.
Then say that the developer who worked on the fix under “windows” now needs to work on another fix and creates “windows_2”. He will be thinking that A is still “A=1”, because that’s how he left it. The developer might go through a painful process to discover that now “A=0”.
How are these types of changes handled, so changes do not get reversed from one merge to the next when branches are created in parallel from the main “trunk”?
Any info will be greatly appreciated.
Thank you very much.
What happens when “test/4” is merged back to “main”?
This is a non-trivial merge, because the*same* line for "A=" has been modified twice, compared with the common ancestor. This is a clear conflict during the merge, and it won't be an automatic one.
So the developer merging back test branch will have to choose between test and windows line, and hopefully, will check with the developer from the windows branch.
From the merge page:
When two or more contributors differ from the base contributor, Diff Merge detects the conflict, and prompts you to resolve it. It displays all contributor differences and you can accept or reject each one.
[changed 10] | [changed to 10 file 2]---
A; | A=1;
-|-
[changed 10] | [changed to 10 file 3]---
A; | A=0
|-
Do you want the CHANGE made in file 2? [yes]
no
Do you want the CHANGE made in file 3? [yes]
yes
Applying CHANGE from file 3 [line 10]
============
But the true answer is communication: if the same file needs modifications (especially in the same lines), there should be some way of managing and coordinating those types of development efforts.
ClearCase also proposed locks on checkout (cleartool checkout -reserved) which would prevent test to be checked out while windows version is checked out. That can also prompt the developer on test to check with his/her colleague, and be aware of the nature of the fix being done.
How to include SVN revision of my project (not file revision) in C source code or in Makefile?
We use a line like this in our makefile:
REPO_REV := $(shell svnversion -n)
That stores the revision number of the working copy into a make variable. To use it in C code, you can have your makefile use that value to define a macro on the compiler command line (something like -DREPO_REV=$(REPO_REV) for gcc).
From the SVN book:
New users are often confused by how the $Rev$ keyword works. Since the repository has a single, globally increasing revision number, many people assume that it is this number that is reflected by the $Rev$ keyword's value. But $Rev$ expands to show the last revision in which the file changed, not the last revision to which it was updated. Understanding this clears the confusion, but frustration often remains—without the support of a Subversion keyword to do so, how can you automatically get the global revision number into your files?
To do this, you need external processing. Subversion ships with a tool called svnversion, which was designed for just this purpose. It crawls your working copy and generates as output the revision(s) it finds. You can use this program, plus some additional tooling, to embed that revision information into your files. For more information on svnversion, see the section called “svnversion—Subversion Working Copy Version Info” in Chapter 9, Subversion Complete Reference.
Normally, the first committed version should start from 1. Version 0 is identical with branch point. But now I got a only version 0, and this prevent me to checkin any other version coz it warned me that the branch already created.
As explained in "Before adding files and directories to source control", the version 0 is a placeholder marking the start for all versions in a given branch:
You can end up with only the version 0 when you undo-checkout a file you just checked out in a new branch (in that case, only a version 0 for the newly created branch remains).
Regarding branches, you can have error like "element already has a branch of type branch", but only when there is an issue with the server and client time (clock) being not in sync.
ClearCase creates version 0 when you create an element (or a branch), which is usually checked out automatically. Version 0 is always either empty, or same as the branched version, as you noted. There shouldn't be any problem simply checking in version 1 on top of it.
Note that branches are created when you check out, not when you check in, so you shouldn't get any warnings on check-in. If you post the exact command line and warnings/errors, we'll probably be able to help you out more.
It could perhaps be that you've created a new element on your branch, and you're missing "/main/0 -mkbranch" in your config spec.
HTH.
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).