Centralized Config Spec for ClearCase Snapshot Views

Question

We have a config spec that we use for our builds that we encourage all developers in our organization to use so that they can run any task in our build without fear of failure. Every now and again we need to update that config spec to include new elements or exclude old elements.

When we do this, the process is to write a quick mail to all of our developers telling them to manually update any views that they use to build our system with the current config spec.

This is annoying and error prone and thus leads many developers to just ignore those mails and then we get called because the build's broken.

I'm very interested in defining the config spec centrally somehow so that all views can use that config spec and we can update it underneath of people. This may seem draconian but when you have hundreds of developers and they're all supposed to be running the same builds, it seems to make sense.

I've already investigated the idea of using a share to store the config spec and then include it in the developer's views using an include line, but as the documentation states: "Include files are re-read on each execution of setcs and edcs." This appears in testing to mean what it seems to mean, that the only time the rules are re-evaluated are in the context of editing the config spec in some way.

The solution I'm looking for would re-evaluate the config spec every time you interact with clearcase, or at the very least update. In that way, I could manage the config spec for everyone.

Thoughts?

Answer 1

I can work, especially if your included config spec doesn't change too often.
Each time it will change, your users will have to run

cleartool setcs -current

(as explained in the example#2 of this technote)

You will then need to decide where to store that common config spec:

• on a share drive
• on a ClearCase view in order to benefit from the history feature for that common config spec content.

You can see a full debate in this thread:

However, I have encountered situations where a version controlled include file was necessary because it referred to plenty of elements from a legacy code which users had to use to continue their work on some of the new code. It was pain and we had to live with it.

Just like with any other 'process', this too needs some 'education' to the users.