2

I'd like to understand what makes ClearCase create paths like these (more than one @@):

\TUNE\Integration\XmlFiles\PM_Content@@\main\integ_mp1601\4\CommunityLink.png@@\main\integ_mp151\151x\1

Rather than the more typical (single @@): \TUNE\Integration\XmlFiles\PM_Content\CommunityLink.png@@\main\integ_mp160\160x\1

I don't seem to have a control over it and it is not immediately obvious to me why CC does that. And when it happens there seems to be nothing I can do to "convince" it to use the simpler format.

V. Bogd
  • 33
  • 3

1 Answers1

2

First, a bit of context:

'@@' is linked with dynamic views

You can see that concept with version extended path: using a pathname_ccase syntax, you can add characters to the end of a relative or full path name, turning it into a VOB-extended path name.
VOB-extended path names that specify versions of elements are the most commonly used; they are called version-extended path names.

/vobs/proj/foo.c@@/main/motif/4

That means you can:

The idea is: in a dynamic view, you can access (read the content of) any version of a file through the extended pathname.

Now, why multiple '@@'?

The documentation adds:

This symbol is required to effect a switch from the standard file/directory namespace to the extended element/branch/version namespace.

There are two equivalent ways to think of @@:

  • When appended to the name of any element, the extended naming symbol turns off transparency (automatic version-selection).
    Thus, you must specify one of the element's versions explicitly.
  • The extended naming symbol is part of an element's official name.
    For example, foo.c is the name of a version (the particular version that appears in the view); foo.c@@ is the name of the element itself.

So with:

TUNE\Integration\XmlFiles\PM_Content@@\main\integ_mp1601\4\CommunityLink.png@@\main\integ_mp151\151x\1

You have:

  • PM_Content@@ the name of the element (folder) PM_Content at its version \main\integ_mp1601\4
  • CommunityLink.png@@ the name of the element (gile) CommunityLink.png at its version \main\integ_mp151\151x\1

That happens when the current PM_Content folder, visible in the view, no longer lists CommunityLink.png (which was deleted/rmname'd):

  • you need to select the right folder version (which does list the file)
  • then you can access to any version of the file you want
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Great explanation. I'm merging the ComunnityLink.png from a newer branch into two older ones. For the `\main\integ_mp160\160x` branch the merge worked without producing the multiple @@s. But it won't work for the `\main\integ_mp151\151x\` branch. The problem is that I need to pass the version to a tool that can't handle the multiple @@s. – V. Bogd Aug 21 '20 at 12:10
  • @V.Bogd I agree. That, or you need to make sure the version of the folder list the file. – VonC Aug 21 '20 at 12:32
  • I get it to list the file by merging the version of `PM_Content` that introduced the png with the `PM_Content` at the branch. At this stage I have the png file listed but empty. Then I merge the file itself and it is no longer empty. From there on, I've tried creating new versions for both the contents folder and the file but checkins remain reported with the original PM_Contents version number plus the file version which keeps incrementing. – V. Bogd Aug 21 '20 at 13:11