Staging Derived Objects

Making elements out of derived objects, and checking them in, is a common practice.

It is even recommended by IBM/Rational (and was already by Atria) as a procedure used internally in the development of ClearCase.

Why is it a bad advice?

First and in general, it preempts the generation (winkin) of a configuration item consistent with the rest of the software configuration, under the control of the system, and trades this for the selection of an object, under the control of the developer.
The developer builds with his own modifications included, which may or may not invalidate the opaque object selected via the config spec This cannot be asserted by the tool anymore.
Bottom line: this lowers the level of support offered by the SCM, and shifts back to the developer part of the responsibility the tool was meant to take.

In the context of ClearCase, and of derived object management, it does however worse: it turns gold into lead.

It takes some blindness not to see that under an SCM based on clearmake like functionality, derived objects are a higher order configuration item candidate than source elements. Taken as versions, the derived objects are (from the point of view of the build system) opaque objects, all equivalent in a flat world void of any dependencies.

Why is it done then?

The reasons are many:

• lack of confidence in the reproducibility of one's builds
• lack of confidence in one's file storage (having a mythical faith in ClearCase storage being safer)
• side-effects and workarounds for deficiencies in the control over one's environment (using ClearCase as a plain nfs/cifs file server, or MultiSite as a plain distribution tool)
• performance optimization: saving the time of building the derived objects, or even validating the existing ones or winking them in; saving in fact the effort of optimizing and/or fixing one's build system.

Add offense to injury

It is even common to store large binaries (jars, zips, and other such beasts), often with unique names e.g. including timestamps (thus as evil twins). These will in any case be stored in full copies, even if the differences result from one byte change in the original sources. It won't take long before these monsters result in performance degradation, and are the source of various errors (e.g. resource exhaustion).

-- MarcGirod - 21 Mar 2009