2

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?

Community
  • 1
  • 1
Robert S.
  • 1,942
  • 16
  • 22

1 Answers1

1

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you for your answer. 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. – Robert S. Jun 22 '16 at 08:55
  • The argumentation that `dir` is a Windows command is not that satisfying as `copy` is a Windows command too and can find the label file. – Robert S. Jun 22 '16 at 08:56
  • @RobertS. OK, I have amended the answer to remove the non-visible dir argument, and to emphasize the actual issue. – VonC Jun 22 '16 at 09:40
  • Thank you. I think the `dir` solution should work when `copy` works and `copy` should work with extended pathnames. With "once-per-element", `dir` seems to work in any case in our environment. – Robert S. Jun 22 '16 at 10:56