我们有一个配置规范，我们用于构建，我们鼓励组织中的所有开发人员使用它们，以便他们可以在我们的构建中运行任何任务而不用担心失败。我们不时需要更新该配置规范以包含新元素或排除旧元素。
当我们这样做时，过程是向我们的所有开发人员写一封快速邮件，告诉他们手动更新他们用当前配置规范构建我们系统的任何视图。
这很烦人且容易出错，因此导致许多开发人员忽略这些邮件，然后我们会因为构建被破坏而被调用。
我非常有兴趣以某种方式集中定义配置规范，以便所有视图都可以使用该配置规范，我们可以在人们的下方更新它。这可能看起来很严苛但是当你有数百个开发人员并且他们都应该运行相同的构建时，它似乎是有道理的。
我已经调查了使用共享来存储配置规范的想法，然后使用include行将其包含在开发人员的视图中，但是documentation states：“包含文件是重要的 - 每次执行setcs和edcs时都读。“这在测试中表示它意味着什么，重新评估规则的唯一时间是在以某种方式编辑配置规范的上下文中。
我正在寻找的解决方案会在每次与clearcase交互时重新评估配置规范，或者至少更新。通过这种方式，我可以为每个人管理配置规范。
思想？
答案 0 :(得分：2)
我可以工作，特别是如果你所包含的配置规范不经常改变的话 每次更改时，您的用户都必须运行
cleartool setcs -current
（如example#2 of this technote中所述）
然后，您需要决定存储该常用配置规范的位置：
您可以看到full debate in this thread：
但是，我遇到了版本控制的情况 包含文件是必要的，因为它提到了很多元素 来自用户必须用来继续他们的工作的遗留代码 新代码。这很痛苦，我们不得不忍受它。
就像其他任何“过程”一样，这也需要一些“教育” 用户。