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".
Related
/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.
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.
The "About" of most computer programs have a version number, such as "2.1" where usually the first number is the major release and the second number is the minor release. At times the version number is followed by the build number enclosed in parentheses like "2.1 (456)" and more often than not, the build number is a 4 figure number. So I was wondering, how do programmers keep track of the build number?
For Windows, versioninfo resource updated (by build-system) from hand-made data of with information from used VCS
For software produced on OS X, the build number is typically managed using Apple Generic Versioning. You can read the man page for agvtool to get started.
Here are some basic use cases for agvtool:
$ agvtool what-version
$ agvtool next-version -all
$ agvtool new-version -all 456.7
Here's an article from Dave Dribin about how to use it. It's up to the developers to determine when the number should be incremented. (Examples of when you might increment the build number: for every commit, for a daily build, for a weekly build, for every build that is distributed to testers)
...specifically, the /AL option? I am porting some ancient C (a Freescale nee Motorala M68000 simulator) and I can't find it on MSDN. Google retrieves many non-related links, and the Wayback Internet Archive chokes beyond the "Product Release" page. Note that this switch seems not to be present in version 6, but resurfaces in .Net as:
"/AL Specifies a directory to search to resolve file references passed to the #using directive"
These files are neither C++ nor C#, su that ain't right...
an example: cl -c -AL CODE1.C
I guess it sets the memory model to Large. That page reminded me of it: http://msdn.microsoft.com/en-us/library/aa225257%28v=sql.80%29.aspx
Oh, those were the days...
Update: Here's the full set: http://gunkies.org/wiki/Microsoft_C_5.1
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.