Converting ClearCase VOB's that have many sym-links hardlink

I am also interested in how to handle symlinks when converting ClearCase projects. We have a common library VOB, which stores validated copies of .jar files, in which other projects symlink to the libraries they need. For security and audit purposes, software developers are not allowed to check in library files into version control, only the configuration management team. I've been told that this functionality was not considered in RTC. Anyone have ideas on how to include a selected list of secured libraries into a project, other than replicating these libraries into every project?

That is correct. The RTC SCM system doesn't yet support the creation of
sym-link versions (feel free to support/comment on work item 40443).
It also doesn't yet support the creation of hard link versions (feel
free to support/comment on work item 58190).

Cheers,
Geoff


thebigring wrote:

Is there a way to import a complex ClearCase env to RTC?
By complex I mean many hardlinks, sym-links and hard coded Makefiles.
I heard that RTC does not have sym-links.

Thank you,

"53x11"

Could you clarify why the ability to have version-controlled sym links
solves the problem of a user not being able to check in library files?

Cheers,
Geoff

vrcampbell wrote:

I am also interested in how to handle symlinks when converting
ClearCase projects. We have a common library VOB, which stores
validated copies of .jar files, in which other projects symlink to
the libraries they need. For security and audit purposes, software
developers are not allowed to check in library files into version
control, only the configuration management team. I've been told that
this functionality was not considered in RTC. Anyone have ideas on
how to include a selected list of secured libraries into a project,
other than replicating these libraries into every project?

What would you suggest for a migration path when the build depends on hardlinks and symkinks? Is there support to migrate a complex system from ClearCase to RTC? Where the VOB's have links to other VOB's. Does this mean we need to re-architect our entire system? What error is shown during import when the system finds sym or harlinks?

That is correct. The RTC SCM system doesn't yet support the creation of
sym-link versions (feel free to support/comment on work item 40443).
It also doesn't yet support the creation of hard link versions (feel
free to support/comment on work item 58190).

Cheers,
Geoff


thebigring wrote:

Is there a way to import a complex ClearCase env to RTC?
By complex I mean many hardlinks, sym-links and hard coded Makefiles.
I heard that RTC does not have sym-links.

Thank you,

"53x11"

Could you clarify why the ability to have version-controlled sym links
solves the problem of a user not being able to check in library files?

Cheers,
Geoff


Geoff,
In our environment, software developers can freely link to any authenticated library file from a secured repository. Library files that developers check in themselves are not guaranteed to be free of malicious code or undocumented changes, especially if they have the same name as a commonly used open source library. OK, this probably wouldn't happen, but our audit standards and guidelines state that we cannot allow this potential exposure. This is only an issue because our project design relies on imbedded runtime libraries in the .war file. Other places I've worked allowed no runtime libraries in the distribution files, and that all runtime libraries were securely maintained on the server. Developers could check in any library file they needed to compile. In our environment, this is somewhat difficult because our applications are sent to servers that we do not own or operate. Could we have two distribution files, the application and the runtime libraries? Maybe. We've kicked around some ideas on how to use and validate the authenticity of library files in our current environment. We've previously solved this using symlinks but we need to implement an alternate method of handling them. Aside from that, it is more efficient to allow 10 projects to use one copy of a library instead of 10 copies of the same library in 10 projects.

There is no automated way of refactoring your source code tree to not
use symbolic or hard links. But one common approach that avoids having
to change many/any of your build scripts is to introduce an initial
build step which performs a "copy" to produce the appropriate files in
the locations of the sym links and hard links. In the case of hard
links, you'd have to decide which of the hard links is the "real" file,
and the rest would be created by this build step.

WRT how this is handled by the ClearCase Connector:
- The file that has multiple hard links to it will be located at
whatever was the last location that was processed for it. Effectively,
the synchronizer "moves" the file to that location.
- For symbolic links, the synchronizer creates a text file containing
the symbolic link. When exported back to ClearCase, it will
create/update the symbolic link in ClearCase. So symbolic links are
preserved, but they do not act as symbolic links while they are in the
Jazz file area (sandbox).

Cheers,
Geoff



thebigring wrote:

What would you suggest for a migration path when the build depends on
hardlinks and symkinks? Is there support to migrate a complex system
from ClearCase to RTC? Where the VOB's have links to other VOB's.
Does this mean we need to re-architect our entire system? What error
is shown during import when the system finds sym or harlinks?

gmclemmwrote:
That is correct. The RTC SCM system doesn't yet support the creation
of
sym-link versions (feel free to support/comment on work item
40443).
It also doesn't yet support the creation of hard link versions (feel

free to support/comment on work item 58190).

Cheers,
Geoff


thebigring wrote:
Is there a way to import a complex ClearCase env to RTC?
By complex I mean many hardlinks, sym-links and hard coded
Makefiles.
I heard that RTC does not have sym-links.

Thank you,

"53x11"

You must be a Unix-only shop, right? (Since the windows file system
does not support symbolic links). Or are you taking advantage of
ClearCase's ability to "fake" symbolic links on Windows (directly in
MVFS, and by creating copies in snapshot and web views)?

In either case, Jazz SCM does not support symbolic links, so you'd need
to get rid of the symbolic links if you were switching to Jazz SCM. In
particular, I'd suggest using the technique I described earlier in this
thread, i.e. introducing an initial "build" step, that creates copies in
the locations where symbolic links exist today.

Cheers,
Geoff

vrcampbell wrote:

Could you clarify why the ability to have version-controlled sym
links
solves the problem of a user not being able to check in library
files?
Cheers,
Geoff


Geoff,
In our environment, software developers can freely link to any
authenticated library file from a secured repository. Library files
that developers check in themselves are not guaranteed to be free of
malicious code or undocumented changes, especially if they have the
same name as a commonly used open source library. OK, this probably
wouldn't happen, but our audit standards and guidelines state that we
cannot allow this potential exposure. This is only an issue because
our project design relies on imbedded runtime libraries in the .war
file. Other places I've worked allowed no runtime libraries in the
distribution files, and that all runtime libraries were securely
maintained on the server. Developers could check in any library file
they needed to compile. In our environment, this is somewhat
difficult because our applications are sent to servers that we do not
own or operate. Could we have two distribution files, the application
and the runtime libraries? Maybe. We've kicked around some ideas on
how to use and validate the authenticity of library files in our
current environment. We've previously solved this using symlinks but
we need to implement an alternate method of handling them. Aside from
that, it is more efficient to allow 10 projects to use one copy of a
library instead of 10 copies of the same library in 10 projects.

Thanks Geoff, that is one of the solutions we are considering. We've never considered that using the symlink capabilities in ClearCase was "fake" to place a copy of that file in a Windows view, it sure seems real to us. Like I stated before, it surely is more efficient to have 10 projects link to a single version controlled copy than have each project version control the same file.

I didn't mean for "fake" to have a pejorative tone ... perhaps I should
have said "simulate" ... symbolic links are very useful, but
unfortunately, Windows does not provide them (which is one reason why
ClearCase goes to the trouble of simulating them, so you get their
benefit in a Windows environment).

But note that the only two ways to simulate them in a Windows
environment are:
- implement your own Windows file system (such as ClearCase MVFS)
- create copies of the files at the symbolic link sources (such as is
done in ClearCase snapshot and web views)

Since Jazz SCM only provides a copy-based file area, if it were to
support symbolic links on Windows, it would have to use the second
approach, so you would still be paying the overhead of copies being
created ... it's just that the versioning system would be responsible
for creating the copies, instead of the build system.

Cheers,
Geoff

vrcampbell wrote:

Thanks Geoff, that is one of the solutions we are considering. We've
never considered that using the symlink capabilities in ClearCase was
"fake" to place a copy of that file in a Windows view, it
sure seems real to us. Like I stated before, it surely is more
efficient to have 10 projects link to a single version controlled
copy than have each project version control the same file.

Geoffrey Clemm wrote:

I didn't mean for "fake" to have a pejorative tone ... perhaps I should
have said "simulate" ... symbolic links are very useful, but
unfortunately, Windows does not provide them...

Not entirely true: Windows Vista adds symbolic links, and even prior
versions like XP have a lame imitation called junctions (see
<http>).
Now, I realize XP will have to be supported for quite a while yet, but
IMHO it's time for IBM, and the industry as a whole, to get out of the
"can't do symlinks because Windows doesn't support them" mindset and get
into that of "let's begin work on making symlinks first-class objects in
all our tools" because within a couple of release cycles, all supported
platforms will have them.

It's not quite so simple for a Java-based tool such as RTC, since you
presumably have to wait for the Java community to decide to support
symlinks and then till you support that JVM. Fortunately, it appears
that the upcoming Java 7 will add symlink support (in the java.nio.file
package). It would make me quite happy if IBM would say "we will support
symlinks in the first RTC release which supports Java 7". (If in fact
running on Java 7 within a symlink-aware filesystem, of course). This
could be not much more than a year away.

MK