My first recommendation is to find out why the customer is doing this,
and see if there is an alternative that does not involve having two
different pathnames for the same file. In particular, one of the common
uses of this approach is to restructure the file system for "delivery",
because at runtime, it is better for the files to be in different places
than at development time. If so, I'd strongly recommend having the
build system perform this change (i.e. the "compile" step for these
files is a "copy" to the right place), and not play games with the file
system. In particular, based on the names of your two environments
(DEVELOPMENT and DELIVERY), I suspect that is the case in this example.

But any change like this to remove file aliases will of course involve
some work, and if the customer doesn't want to do that work, then you
could consider using symbolic links.

When you say "this seems quite complex and manual", what would be
something simpler or more automatic? If you want a given file to
reference some other file in another project, you'd need to invoke an
operation that says "this file in this project is the same as this other
file in this other project" ... which is basically what a "make symbolic
link" command says. Or were you concerned about the overhead of fixing
up symbolic links when the referencing or referenced file is moved? If
so, yes, that is more complex and manual than something like a Unix
"hard link" (which is why people use hard links in some cases). But
note that hard links are not supported by RTC, and that even if they
were, it would only be available on Unix systems, because Windows file
systems do not support hard links.

Also, note that with RTC, you can load a symbolic link into the file
system only if that file system has native support for symbolic links
(e.g., a Unix file system, Windows Vista, Windows 7, but not Windows
NT). In particular, RTC does not try to "fake" symbolic links on file
systems that do not support it, as ClearCase does.

Which brings me back to my original recommendation to just use the
"build" to create these as copies, and not have different pathnames
aliased to the same file.

Cheers,
Geoff


On 8/4/2010 3:38 AM, pcravino wrote:

I'm trying to figure out how to reuse some resources between different
projects to map different needs. In particular, I may have one full
component in one project and need to link only some elements of this
components into another project.

This is an example:

Project Area DEVELOPMENT
Component COMP1_DEV
Folder FOLDER1
File1
File2
File3
File....
FileN
Folder FOLDER2
FileA
FileB
File...
FileZ
Component COMP2_DEV
Folder FOLDER4
.....
.....
Folder FOLDER5
.....
.....

Now, I need to see only some files of component COMP1_DEV from Project
Area DEVELOPMENT (where developers work) into another Project Area
(where delivery/package is created):

Project Area DELIVERY
Component COMP1_DEL
Folder FOLDERx (local)
File1 (local)
File2 (local)
File... (local)
FileN (local)
Folder FOLDERy (local)
FileA (local)
FileB (local)
File... (local)
FileZ (local)
Folder FOLDERLINK (local)
File1 (this must be the same File1 in FOLDER1 of COMP1_DEV in
Project DEVELOPMENT - cannot be a copy)
File ABC (local)
File3 (this must be the same File3 in FOLDER1 of COMP1_DEV in
Project DEVELOPMENT - cannot be a copy)
File XYZ (local)

All files in this project are local; only File1 and File3 (in this
example) point to the defined baselines of COMP1_DEV in Project
DEVELOPMENT). As soon as a new baseline is created for COMP1_DEV and
is replaced into Project Area DELIVERY, I need to see new version of
File1 and File3 into COMP1_DEL.

What I've done is to add COMP1_DEV (baseline xxxx) into the Stream of
Project Area DELIVERY. Then I think the only option we have here is
to use Symbolic Link to LN the File1 from FOLDER1 into FOLDERLINK,
and this must be done manually for every file.
Do you know if this scenario is correct ? Any different possibility
(as it seams is quite complex and manual) to do the same ?

Thanks!