Winkin

This relates to the issue of identifying the configuration items: technically, elements and derived objects are identified in different ways. This may be seen as a nuisance, as the distinction between them is of secondary importance from the point of view of their users: a source file may even be generated. This is where the concept of winkin steps in.

By winking in already built derived objects, ClearCase not only attempts to save building time (which it doesn't always achieve), but rather attempts to hide this distinction and handle derived objects as far as possible as first class citizen.

This is where we can understand that Version Control and Build Management cannot indeed be separated, but jointly concur to commonly providing a higher level service.

We are speaking here of something which:

• is a decisive advantage of ClearCase specifically
• significantly alters what is commonly understood by the concept of SCM

With ClearCase, every configuration item is identified as a specific choice from a set. This is true for versions of (source) elements. This is also true for derived objects. There are many "versions" of any derived object simultaneously available.

This is decisive to support sharing. Shared items must be at the same time closed and open:

• closed to protect any user from changes beyond his control
• open to allow him to tailor the items to his needs, without forcing him to duplicate (i.e. to resign sharing)

This is easily jeopardized, e.g. through staging.