There are multiple signs that this assumption is breaking down, which is a new frontier for the development of SCM: delivering under SCM, into an environment managed by an SCM tool.

The tools currently considered (e.g. the Eclipse repository) are crude and few even notice that they are meant to perform SCM functions. Let's however notice that there is a case in which a similar requirement has been present for decades: versioned shared libraries.

It is interesting as a pilot case for releasing (to customers) under SCM. The case of shared libraries is just one instance of the more general one. Let's consider it in the context of ClearCase.

One builds (more precisely: links) using a name (1), and one uses the library using another (2).
In (1), it is a good idea that the name is generic, so that changing the version doesn't require updating the build script (referential transparency), but the name recorded in the binaries (2) should guarantee interoperability, and thus not move without a rebuild of the client. Furthermore, the dynamic loader might be able to load different versions of the same library concurrently, if so requested from different applications (unless they use unique resources, such as well-known ports, or locked-schema databases, etc.)

The traditional solution (outside vobs) is thus a fixed name, with version encoded extension (2), and a generic symbolic link (1) pointing to the current version.
What is interesting here, is that this is a "poor man's solution" to an SCM issue.

We might first want to part the case of 3rd party software, meant to run on plain unix, and this of our own applications, running from the vobs.
Although eventually, this distinction might not be relevant.

The traditional thought is that one intends to converge to one consistent combined software configuration, i.e. in this case, to have all applications, depending on a shared library, use the same version. This might be a goal, yet require temporary exceptions. As such, it won't scale well, so that there may be more exceptions and for longer, as the overall system grows.

Eventually, and this is already the case with OSGI repositories, the price of rebuilding old applications (working and possibly running) is felt as impossible to justify: useless instability and downtime.

Back to ClearCase and to hard links.
The first problem with soft links is that they have to point to something so that they do not really offer an alternative to even worse 'copies'. They imply some kind of 'evil twins'.
Unless what they point to is a hardlink of the same element (under a unique, version extended name):

ct ln libfoo.so libfoo.so.27

Why might this help?
Because it allows one to set one's config spec to pick different versions for the different names:

element libfoo.so.27 FOO_27
element libfoo.so.26 FOO_26
element libfoo.so /main/LATEST

Using this, one may access different versions of an element within the same view.
Unfortunately, the linker won't make sense of this without help, and the help requires that one makes version information explicit to the build script (thus breaking the referential transparency).

So, it seems a better idea to have the generic name (here libfoo.so) be a symlink to the current version extended hardlink.
But, this symlink has to be maintained, every time one creates a new hardlink to the library, which is not easier than editing a macro in a makefile (or producing a makefile component automatically as a derived object).

-- MarcGirod - 19 Oct 2009