0

虽然我不确定我对其他 Accurev 问题是否有满意的答案，但我相信我开始理解我在 Accurev 差异中看到的问题。

流程是这样的：

  1. 开发人员 A对 bug 1 进行了一些更改，升级。
  2. 开发人员 A对错误 2 进行了一些更改，升级。
  3. 开发人员 B审查开发人员 A对错误 1 ​​的更改并将其发回以进行进一步更改。
  4. 开发人员 C审查开发人员 A对错误 2 的更改并批准它，这是额外的提升。
  5. 开发人员 A对 bug 1 进行了更多更改，提升。
  6. 开发人员 C审查开发人员 A的错误 1 ​​更改。

最后一步是我感知破损的地方。开发人员 C 无法以任何合理的方式查看与错误 1 ​​相关的所有更改，即使每个事务/版本（无论 Accurev 调用它们）都与该问题 ID 相关联。

如果我对基础进行比较，我会得到所有的错误 2 更改以及所有其他已提升的内容。乘以 30 个开发人员，这是一场噩梦。

如果存在重叠和合并解决方案，它会变得非常混乱，但让我们暂时假设，除非在这种情况下，归属不会出错......即使我看到它不是这样，也可能只是一个误解。

无论如何，假设所有促销都是“干净的”并且（据我了解）新交易是每个开发人员“保留”交易的“别名”交易。

如何查看两个交易的组合差异？

特别是上面第 1 步和第 5 步中的交易。将有两个事务，我只想要在这些事务中所做的更改，并且只需要那些事务。理想情况下，一个格式良好的或 GUI 工具 diff 可以递归地工作（而不是单个文件，整个事情）。

请注意，有效的答案可能是“您做错了”，但应包括有关更改内容的建设性建议，例如“在开发人员的工作区中进行评论”或类似内容。我怀疑我们可能只是用错了。

4

2 回答 2

1

我不会说你做错了，但这里肯定有一些假设。就我而言，从您的描述看来，您显然在示例中使用了一个文件（无论如何，为了简化）并且这些更改是按顺序进行的。

在 AccuRev 中，变更包包含与从基础到头部的“错误”相关的任何文件的上下文。所以当开发者修复 Bug 1 时，文件的“开始”和“结束”版本都归于 Bug 1。无论其他 30 位开发人员此时做什么，您始终可以查看 Bug 1 的更改包，查看更改选项卡，并仅根据与该错误有关的文件来区分文件，即使将一千个其他更改提升到该流中也是如此。

出现困难的地方在于，开发人员假设他已经完成了，随后对属于 Bug 1 的文件进行了更改，将其链接到 Bug 2，然后继续前进。审核完成后，他现在必须对 Bug 1 进行额外的更改，这些更改是在 Bug 2 更改的基础上构建的。

首先，如果您没有选择“更改包合并”，AccuRev 不会让您将该文件提升和链接到错误 1。这意味着在将版本归因于您要链接到的特定错误（特别是对错误 2 的更改）方面存在差距。AccuRev 希望您确认这些错误 2 更改可以隐式包含在错误 1 ​​中使固定。所以我们不会让它偶然发生。但是，如果您决定不希望 Bug 2 更改出现在 Bug 1 内容中，则必须进行一些修补。在您描述的工作流程下，这变得更加棘手，但绝对有可能。最重要的是，您所呈现的场景是没有工具能够自动处理的场景，因为存在与不同错误相关的连续更改。好，让我修改一下，并说没有任何工具可以在“签入评论”之类的东西之外工作，并提供在问题级别而不是文件级别工作的自动化方式。AccuRev Change Package 功能非常强大，将控制权交给您，让您可以在整个开发过程中将 CP 作为对象进行操作。

我希望这能在这个论坛上尽可能彻底地回答你的问题。如果您有其他问题或想更深入地讨论，我们也可以安排。

干杯，
〜詹姆斯

于 2011-01-14T14:58:16.653 回答
0

我相信没有办法查看给定开发人员对文件的更改，在这些更改被提升后，当该文件有多组更改时。

与支持的差异在父非工作区流中没有意义。

Diff against base 有每个人的变化。

请参阅关于Accurev 中的基础和支持之间有什么区别的已接受答案的评论。

于 2011-01-21T16:11:33.810 回答