Critique of the current system

Contents

• General
• Reuse
• Tracking the directories
• Clashing objects
• Clashing symbols
• Delays due to the user rights, and the needs for delegation
• Hidden dependencies (because the build is sequential)
• Bound rules producing many objects
• Traceability
• Related Items

General

I try here to collect problems met with the current system, and which were disclosed during the process of converting it to ClearCase.

Reuse

Reusing files is not well supported. The responsabilities are bound to the POB, which encourages to make copies, and to start diverging from there, instead of maintaining common parts.

As soon as a file is moved to a different directory, which is natural in case of reuse, the history gets broken.

An example of such a divergence can be found between the POBs ouiman and ouisws.
In this case, the whole POB (ouiman) was duplicated for further development. This was a pick-and-paste event, after which the files started diverging, with no hope for them to be maintained in a coherent fashion (emhancements, bug corrections, etc...)

Tracking the directories

The revision numbers are bound to the path where the files are found: there is no notion of element having an identity.

The directories themselves are not versioned. If a file is removed from a directory, there is no access any more to its history!

This was e.g. the case of ouiman/ouitermx.c.

Clashing objects

Nothing prevents that files with the same name (either versions of the same file, or totally different files, either sources or derived objects) exist in various directories.

ClearCase doesn't prevent it either, but it allows to detect which version has been used in a given context.

Such a context may for instance be this of copying the file under the PROJECT directory.

Traceability

Under the RCS based system, there is no support for keeping track of issues like the following:

• Where does a given file in the PROJECT directory come from? This is not trivial since:
  • there may be several copies of it to be found in various places
  • the original copy may have been removed meanwhile
• What version of a resource is a given derived objects based upon? Again, nothing guarrantees that the version to be found currently is the same as the one which was available at the time of building. This may even have changed during the build (POBs processed in the beginning of the build have a different view of the PROJECT directory than POBs built in the end!)
• What product depends on a given resource?

ClearCase offers a powerful tool to help with these problems: configuration records, and the related cleartools: catcr and diffcr.
With catcr, one can trivially answer to the first question, usinf it non-recursively. This may be usefull also e.g. to list the header files (and their actual full path and version!) included while compiling a given source file.
The second question may require a recursive use, and the grepping of the output.
A similar strategy can be used to answer the third question, by applying this approach successively to the main derived objects, then rescursively, down to their constituents to spot the precise uses.

Related Items

• Tasks
• Installation
• Makefiles
• Terminology