Enhancement request: mounting vobs over non-empty directories

Submitted on 21.08.2001. CaseID: v0879045 - CMBU00056479

We maintain our third-party tools in ClearCase vobs.
The benefits we expect from this are:

• Recording the versions used during the builds
• Managing the versions offered, including via MultiSite
• Allowing for simultaneous use of different versions
• Allowing for single-point maintenance, and shielding of users from these tasks

We make this as transparent as possible, via soft links emulating the original locations, e.g. /opt/aCC -> /vob/hp/opt/aCC
Some tools have these paths hardcoded (or nearly so), and could otherwise use non-VOB versions.
We have a script for maintaining these soft links, with three options: set, reset and check.
The reset option will remove the soft links and restore a hidden Unix directory, if locally found, in the standard location.
The script is called at boot time, first with the "reset" option, so that the boot doesn't depend on ClearCase, then later, after ClearCase has been successfully started, with the "set" option.

To update a tool, on a host with a local installation, we reset the appropriate directory, run the vendor installation program, set back the links, and update the vob (using the contrib "citree" utility).

Local licenses must sometimes be maintained, on client machines, and accessed in a generic way.

We are quite satisfied with this scheme, apart for two problems:

• Users without a view cannot access the tools when the links are set. This may be a surprise, e.g. for network administrators.
• For this reason, some tools cannot be put in VOBS, or must be placed elsewhere than in their standard location. They can then be used from there in a way not directly detected, possibly introducing consistency problems.

We are of course aware of some other limitations (e.g. singleton resources forbidding the use of several versions of some tools on the same host), and ready to live with them.

Anyway, an enhancement which could work around the two problems mentioned above would be very valuable: in view contexts, VOBs could be mounted on top of existing Unix directories, in practice hiding them. A special extended path could allow to explictly access the underlying Unix data, e.g. for updating purposes.

Obviously, what we are interested in is the functionality, not the way to achieve it. If mounting VOBs over non-empty file systems is technically not feasible or there are simply better ways, it is obviously fine for us. As Grady Booch said it: "engineer the illusion of simplicity".

I believe that this idea of having a default contents for users without a view may have other applications. E.g. it might apply to the WebDAV view of a vob (see RUC2001/CMA16 - BTW I discussed this proposal at RUC with Geoff Clemm, before he made his presentation)