It's all about the answers!

Ask a question

[closed] CC-RTC-Synchronization creates a wrong directory

Simon Eickel (1.1k75457) | asked May 04 '13, 4:43 a.m.
closed Sep 16 '13, 1:14 a.m.
Hi friends,

this is a new question based on CC-RTC Synchronizer: missing OID in VOB

It only treats the fact that the syncronizer creates a new directory in a wrong directory structure and does not take the folder in CC with the sub vob component which is prepared.

The scenario is the following:
we do have a team which has a root folder inside the component named the same like the component. This is because when they load the component within VS they want to have a folder named like the component without using the option "load component as root folder" ;)
And on this configuration they have build scripts.

Now they need to sync all data of RTC into CC for other teams using it within CC.
But in CC they need the same folder structure as in RTC because of the build scripts. This is with the synchronizer by default not possible (because component is one folder and the top level folder itself is a folder).
This is why we have a subfolder "DO_NOT_USE" where we sync the RTC stuff and at the same level next to the "DO_NOT_USE" folder we have the folder structure we need created as symlinks.
The problem now was, that after applying the subvob attribute to the correct folder within the "DO_NO_USE" folder and starting the sync, the syncer did not sync the stuff into the "DO_NOT_USE" folder but he "changed" the symlink into a real directory and synced into it... Now we had two folder with the same attribute but the syncer took everytime the folder one level too high...

Even after removing all Components from the sctream and syncing - syncer was successfull.
Now I added the component I tried to sync after reconfiguration and started synchronization and now he created the directory next to the "DO_NOT_USE" folder again.
So I'm back at the state where I was before I created this entry at
Now I did what you explained me -
- removed the component from the sync list
- did an rmname on the folder on CC side
- run ccc clones -X -c <comp> on the component
- added it back to the stream.

He still creates this hated directory ... and does not take the one I've marked with the attribute inside the "DO_NOT_USE" folder... :(

even after creating a new sync stream he creates a directory instead of taking the one which is marked to...

Now I read in "Known Limitations of sub-vob component mapping"  the following:
Moving sub-VOB component attribute: Even if you remove the attribute from one folder and add the same attribute to another folder, the synchronizer recognizes that they are different components. Technically, there is no move operation of a sub-VOB component attribute.

This means that this is not possible what I try to do? Is there any solution on this problem?


The question has been closed for the following reason: "The question is answered, right answer was accepted" by eickel Sep 16 '13, 1:14 a.m.

Accepted answer

permanent link
Masabumi koinuma (46115) | answered May 04 '13, 11:31 a.m.
If I understand it correctly, you have RTC component whose structure is like:

RTC component 'Foo'
+-- top-level folder 'Foo'

And In the ClearCase-side, you'd like to have a structure like:

VOB '\Bar'
+-- folder 'DO_NOT_USE'
      +-- sub-VOB component 'Foo' being sync'ed with RTC component
            +-- a sub folder 'Foo' in sync
+-- symbolic link to the sub folder 'Foo'


When you add a synchronization root from RTC-side to the synchronized stream using the "Select Files and Folders" wizard, it initially creates a sub-VOB component folder at the VOB root ( to be more precise, it looks up 'COMPONENT_VOB_TAG' property and create sub-VOB component folder under there). It does not look up the sub-VOB component attribute unless you previously syncrhronized the sub-VOB component folder. That is the reason you probably see a structure like this:

VOB '\Bar'
+-- sub-VOB component 'Foo' being sync'ed with RTC component
      +-- folder 'Foo' in sync

After adding the component from RTC-side to the synchronized stream.
BUT, once you synchronize the sub-VOB component, you can move the folder to the desired structure.
In summary, the step would be like:
- a create a synchronized stream
- set 'COMPONENT_VOB_TAG' property to a desired ClearCase VOB
- make sub-VOB component attribute type on the VOB
- add a synchronization root from RTC-side
- confirm synchronization completes successful
- in the ClearCase side, move the sub-VOB component folder 'Foo' under 'DO_NOT_USE' ( using 'cleartool mv' or its GUI alternative )
- run synchronization again to confirm the component is still in sync
- create a symbolic-link as desired.

Also, another alternative is to synchronize RTC component to a VOB root without using sub-VOB component. In that way, you can see similar structure in the ClearCase-side.
Simon Eickel selected this answer as the correct answer

Simon Eickel commented May 06 '13, 1:57 a.m.

Hi Masabumi,
thanks for clarification. This helped.
The alternative with each component as a VOB is no option.

Concerning your statement "...It does not look up the sub-VOB component attribute unless you previously syncrhronized the sub-VOB component folder."
This is just curious as the first synchronization worked directly with the sub-VOB component and only when adding a new component to the stream and to the synchronization he ignored the sub-VOB component attribute and created an own sub-VOB component folder at the VOB root...

Masabumi koinuma commented May 06 '13, 10:58 a.m.

Hi Simon,

Note that the way it works is totally different if you add a synchronization-root from ClearCase as opposed to add one from RTC SCM.

When you add one from the ClearCase-side, it looks up the sub-VOB component attribute and the folder marked as sub-VOB component is brought over as an RTC Component.

When you add one from RTC SCM-side,
(1) it first looks up a clone link of the RTC component to see if it is previously synchronized. If it finds a component, the RTC component is synchronized to the linked ClearCase component
(2) if there's no clone link for the RTC component, it looks up the 'COMPONENT_VOB_TAG' property. I think the rest of the step is well explained in this page:
And as you see in the page, the 'export' step does not look up the sub-VOB component attribute.

Simon Eickel commented May 10 '13, 5:06 a.m.

Hi Masabumi,

if this is the way the synchronizer should be working there is a bug.
I noticed that when I first create a synchronization from RTC to CC using the subVOB component tag he's synchronizing to the folder which has the attribute and not directly under the VOB root ... this did only happen with the last component I added in a later step.

Simon Eickel commented May 10 '13, 5:14 a.m.

Hi Masabumi,
when reading again this documentation I understood it as before:

If the COMPONENT_VOB_TAG property in the ClearCase Provider Properties of the synchronized stream is set, the synchronization process looks for a sub-VOB component with the name that matches the Rational Team Concert component. That sub-VOB component must be under a VOB with a tag that matches the COMPONENT_VOB_TAG property of the synchronized stream. Then, the synchronization process can export the Rational Team Concert component.

This means that the synchronizer should synchronize the component to the folder with the attribute ... shouldn't it?

Simon Eickel commented May 10 '13, 5:16 a.m.

this means if I create folder (named the same as the component) and add the subVOB component attribute everything should be fine...

but in the case I wrote the last time he didn't use this folder ... no he created an own folder at the top level of the VOB ...

Maybe it has something to do with creating the component on RTC side to a later state after the initial synchronization was done ...
Bug oder Feature?

Masabumi koinuma commented May 13 '13, 11:52 a.m.

Hi Simon, we're trying the scenario in-house to understand it more. Here is a ticket to track the testing.

Investigate: CC-RTC-Synchronization creates a wrong directory (264732)

cunxia sun commented May 17 '13, 10:13 a.m.

(sorry, I posted a comment a couple of days ago, just found out it was not really published. sorry for the delay of a reply -)

 We run a test on this case, and it seemed the behavior is as expected. Simon, could you please take a look at comment 1 of workitem 264732 and see if this is the same setup as yours? please let me know if there is something else you want us to try.


showing 5 of 7 show 2 more comments