We have a team migrating from ClearCase to RTC.                         

They make extensive use of links and this has had an impact on their build.                                                             

Their build approach has been to load the code onto a Windows machine and then remote mount the filesystem from their non-windows systems. The goal is to ensure common code is used for the parts of the system that can be delivered on non-Windows platforms. The main part of the build is native Windows (Visual Studio). The cross-platform backend is built under Cygwin (for Windows), Linux, and MacOS. 

Under ClearCase, this approach worked - the snapshot view would interpret the links and the non-Windows systems would be able to use relative directories to successfully traverse the links. 

RTC, however, simply translates the links to shortcuts. The result is:  

1 - The native Windows builds are able to use relative directories to traverse the links as before - RTC takes the links and maps them to Windows-native shortcuts, so this is expected.  

2 - The Cygwin-based subset fails, because the relative directories are no longer valid (the shell changes current directory context when a link is traversed). Once you go 'down' through a link, you move to that location, thus 'up' takes you to a different tree. 

3 - The Linux and MacOS subsets also fail as the network mounted filesystems (CIFS) do not follow the links quite correctly either - it will not traverse them.                                                                                            

The problem is that the relative paths are encoded into the makefiles and there are many of them. They have tried a number of variations on the 'creative folder mounting' theme (i.e. using CIFS tools to simulate the links using network mounts). 

So, they have asked us to consult IBM and the Jazz community for best practices for handling this scenario in a migration situation before they go in and refactor their makefiles to make them 'relative directory proof'