I want to list all labels of a specific file in ClearCase. Based on the last approach in the accepted answer at (how to find all the labels for a given file in clearcase) I want to use a combination of cd and dir. I only use dynamic views and as we have thousand of versions I guess this approach is much faster than a slow cleartool query (ClearCase is slow as hell here). For info I work on Windows only.
Here is the mentioned approach:
cd m:/myView/path/to/addon.xml##
# list all files, not directories: the files are the labels
dir /B /A-D
Unfortunately the approach does not work for every file. The strange thing is that the label files do not appear in the directory even if there are labels on the checked-in file. The label files exist only in the branch folders.
The stranger thing is that the following works: copy filename##\labelname targetfile. And even a copy labelname targetname works from within the directory "filename##". I don't get it. Why doesn't dir show these files? I tried all attributes (like hidden files) and so on.
Is this a bug in MVFS or am I missing something? As I said it works for many files but not for all. But I don't know what is different with those files. Maybe the file extension/type? But should this matter?
I don't get it. Why doesn't dir show these files?
Because dir is a Windows command which will list Windows filesystem files, not MVFS (Multi-Version FileSystem) ones, used by a dynamic view.
I don't know what is different with those files. Maybe the file extension/type?
Everything after the ## is a version-extended pathname (see man page), emulated as a Windows file by the MVFS dynamic view.
But should this matter?
If you are using Windows commands (and not cleartool queries), it should not, as those extended paths are supposed to be directly visible by Windows.
They are accessible (copy filename##\labelname targetfile), but should be also visible (listed by a Windows filesystem-based dir command)
In particular, for Version labels in extended namespace:
Version labels appear in the extended namespace as hard links (UNIX and Linux) or as additional files (Windows).
On Windows, if version \main\4 of an element is labeled RLS_1, the extended namespace directory corresponding to the element's main branch lists both 4 and RLS_1:
Z:\myvob\src> dir sort.c##\main
2006-11-10T17:34 1846 4
...
2006-11-10T17:34 1846 RLS_1
If the label type was created with the once-per-element restriction, on Windows, an entry for the labeled version appears in the element's top-level directory:
Z:\myvob\src> dir sort.c## 2006-11-10T17:34 1846 RLS_1
Don't forget also that a pathnames can involve multiple elements:
After a path name crosses over into the extended namespace with ##, you must specify a version for each succeeding element in the path name.
For example:
To automatically select versions for elements proj and src: cross over to extended namespace at directory element include, specifying a version of include and a version of sort.h:
Windows:
\proj_vob\src##\RLS_1\include\RLS_1\sort.h\RLS_1
The OP adds in the comment:
The problem was the once-per-element restriction. This is the default setting in our environment but someone used the once-per-branch setting in his VOB. So the label files could not be created at the top-level directory.
The once-per-element restriction is the mklbtype default.
A mklbtype -pbranch command creates a label type that can be used once on each branch of an element.
Related
Background
In Clearcase, you can get the graphical version tree of a file by entering the following command in a linux terminal.
ct lsvtree -gra <filename>
This brings up an interface with numerous options to look at the diffs between two versions of a file.
Problem
From the graphical tree interface, I am trying to find if a string exists across any version of the file. This string was lost at some point, and I want to figure where that "somepoint" is.
Question
How can I run a text search across all versions of a file in clearcase?
As I mentioned before (2015), there is no equivalent to a git log -S or -G (pickaxe search) in ClearCase.
That pickaxe search is done (in Git) to point out past revision where a string has been added or removed.
But: you would need to script the equivalent feature for ClearCase.
Since cleartool lsvtree shows you all the version of a given file, you can, starting with the most recent version do a cleartool annotate to see when, and in which version, the line was added.
If that line include your string, then this version would be relevant.
If the most recent version does not include your string, then repeat the process with the previous version (do a cleartool annotate on that previous version, if it includes your string).
If you use dynamic views, you could take advantage of how it accesses element versions via version-extended naming. using "foo.c##/main/branch/1" as an example, you have "foo.c##" as the root of a directory structure, with "main" and "branch" being subdirectories, and "1" being a "file"
You can use this by doing the following:
cd to "foo.c##"
Perform your search.
For example:
cd foo.c##
grep -rl "target-string" *
to get the files without the string:
cd foo.c##
grep -rlv "target-string" *
You could also use lsvtree output to power a search in a script, but the above is is the simplest trick to do this. This works on Unix and Windows, but you may want to use something other than the standard Windows "findstr" if your target string contains multiple words, as findstr handles them strangely: findstr "foo bar oof" will print lines that contain "foo", "bar", or "oof", occasionally even when /L for "literal" is used.
If you're using snapshot or web views, this is a lot trickier and will need a script to iterate on the output of lsvtree.
I often see "./..." in makefile. I think it means it is all subfolders in the current directory. Could someone confirm and provide me the source where this syntax is explained?
Example:
go generate ./...
The import path pattern ./... matches all packages in directories below the current directory, except those in vendor directories.
The pattern is implemented by the go tool. The pattern is not interpreted by make, bash and any other tool that might invoke the go tool.
The documentation for the go command says:
An import path is a pattern if it includes one or more "..." wildcards, each of which can match any string, including the empty string and strings containing slashes. Such a pattern expands to all package directories found in the GOPATH trees with names matching the patterns.
To make common patterns more convenient, there are two special cases. First, /... at the end of the pattern can match an empty string, so that net/... matches both net and packages in its subdirectories, like net/http. Second, any slash-separated pattern element containing a wildcard never participates in a match of the "vendor" element in the path of a vendored package, so that ./... does not match packages in subdirectories of ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do. Note, however, that a directory named vendor that itself contains code is not a vendored package: cmd/vendor would be a command named vendor, and the pattern cmd/... matches it. See golang.org/s/go15vendor for more about vendoring.
and it also says:
An import path beginning with ./ or ../ is called a relative path. The toolchain supports relative import paths as a shortcut in two ways.
First, a relative path can be used as a shorthand on the command line. If you are working in the directory containing the code imported as "unicode" and want to run the tests for "unicode/utf8", you can type "go test ./utf8" instead of needing to specify the full path. Similarly, in the reverse situation, "go test .." will test "unicode" from the "unicode/utf8" directory. Relative patterns are also allowed, like "go test ./..." to test all subdirectories. See 'go help packages' for details on the pattern syntax.
Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces, but such programs cannot be installed with "go install" (there is no work space in which to install them), so they are rebuilt from scratch each time they are built. To avoid ambiguity, Go programs cannot use relative import paths within a work space.
Is it possible to globally ignore a folder IF it is a child of a folder having a specific name? For example...
Exclude:
client/vendor
... or ...
app/vendor
But never exclude a "vendor" folder if it appears anywhere else?
I'm working on an AngularJS project and the "vendor" folder is common for client-side files. However, theoretically, it is possible that "vendor" may have another meaning in future projects and, if it does, it would generally be in another path.
The docs on this are a bit misleading (to me, anyway). It says to use the svn:ignore property but no examples anywhere show how to specify the conditional parent folder. They all appear to be manually ignoring a specific folder every time... via a command line.
Per the TortoiseSVN docs:
No Paths in Global Ignore List (Link here) You should not include
path information in your pattern. The pattern matching is intended to
be used against plain file names and folder names. If you want to
ignore all CVS folders, just add CVS to the ignore list. There is no
need to specify CVS */CVS as you did in earlier versions. If you want
to ignore all tmp folders when they exist within a prog folder but not
within a doc folder you should use the svn:ignore property instead.
There is no reliable way to achieve this using global ignore patterns.
I found out that labels must be applied starting at the VOB if you want to successfully recreate a specific code (label) release. I thought you wouldn't have to start at the VOB name but you do :-(
My VOB has many programs in it. For example:
VOBname\programs\Java\Program1\files...
VOBname\programs\Java\Program2\files...
VOBname\programs\VB\Program1\files...
VOBname\programs\VB\Program2\files...
What I would like to do is have a script or program that takes two parameters, a path and label, and applies that label to the proper directories and files in that path.
It should not apply the label to other, non related, directories (i.e., if I am labeling Java\Program1 it should not also label Java\Program 2.
I also need the reverse - If someone incorrectly applies the label, then I need to remove the label from the path.
It seems like this feature would have been incorporated into the GUI or a script long ago but I don't see one available. Of course, you can do this manually but this takes longer especially if you have a long path.
I know you can label a directory and all contents underneath that directory but if you start at the VOB, that would label everything (what I don't want).
The simplest solution is to:
apply recursively a label from the path
cd /path
cleartool mklabel -replace -recurse LABEL
for a given path, extract the parent folders, and label those:
avob/
avob/aParentFolder
avob/aParentFolder/aParentSubFolder
Depending on your scripting language, extracting the parent folders can be as easy as perl File::Basename
my($filename, $directories, $suffix) = fileparse($path);
# On Unix returns ("baz", "/foo/bar/", "")
fileparse("/foo/bar/baz");
Because ClearCase updates directory version numbers when files inside are created, our config-spec generating script is failing (details omitted).
So, as an example, given a file such as "/proj/src/scripts/build.sh##/main/branch42/3", how can we determine the latest version of the scripts directory that contains that version of the build.sh file.
Note: we're looking for a unix command-line solution that can be scripted.
If you do a ls /proj/src/scripts##/main/branch42/*/build.sh/main/branch42/3 you should get a list of all versions of the scripts directory that contain version .../3 of build.sh. Then you should be able to pick out the latest of those.
The above is probably not a fool proof approach, so you might try something more like
cleartool find /proj/src/scripts --allversions --nonvisible -name build.sh -version 'brtype(branch42) && version(3)' -print
(I no longer have a clearcase environment to test in, so the above is from memory and is not an accurate command)
Another approach is to:
set a label on the right version of the build.sh script and its directory (you can move that label when needed)
have a second dynamic view always configured to select that label
element * SCRIPT_LABEL
element /proj/... .../branch42/LATEST
That way, you simply read the information you need from that second dynamic view.