2

我们有一个用于构建的配置规范,我们鼓励组织中的所有开发人员使用它,以便他们可以在我们的构建中运行任何任务而不必担心失败。时不时地,我们需要更新该配置规范以包含新元素或排除旧元素。

当我们这样做时,该过程是向我们所有的开发人员写一封快速邮件,告诉他们手动更新他们用于使用当前配置规范构建我们的系统的任何视图。

这很烦人且容易出错,因此导致许多开发人员忽略这些邮件,然后我们因为构建损坏而被调用。

我对以某种方式集中定义配置规范非常感兴趣,以便所有视图都可以使用该配置规范,我们可以在人们的下方对其进行更新。这可能看起来很苛刻,但是当您有数百名开发人员并且他们都应该运行相同的构建时,这似乎是有道理的。

我已经研究过使用共享来存储配置规范,然后使用include一行将其包含在开发人员的视图中的想法,但正如文档所述:“每次执行 setcs 和 edcs 时都会重新读取包含文件。” 这在测试中似乎意味着它似乎意味着,重新评估规则的唯一时间是在以某种方式编辑配置规范的上下文中。

我正在寻找的解决方案将在您每次与 clearcase 交互时重新评估配置规范,或者至少是更新。这样,我可以为每个人管理配置规范。

想法?

4

1 回答 1

2

我可以工作,特别是如果您包含的配置规范不经常更改。
每次它会改变,你的用户将不得不运行

cleartool setcs -current

(如本技术说明的 example#2 中所述)

然后,您需要决定在哪里存储该通用配置规范:

  • 在共享驱动器上
  • 在 ClearCase 视图上,以便从该常见配置规范内容的历史记录功能中受益。

您可以在此线程中看到完整的辩论

但是,我遇到过需要版本控制的包含文件的情况,因为它引用了遗留代码中的大量元素,用户必须使用这些元素才能继续处理一些新代码。这是痛苦的,我们不得不忍受它。

就像任何其他“过程”一样,这也需要对用户进行一些“教育”。

于 2012-01-27T19:48:21.830 回答