如何在没有任何继承更改的情况下获得 Accurev 中问题的差异？
虽然我不确定我对 有一个满意的答案我的另一个 Accurev 问题，我相信我开始理解我在 Accurev 差异中遇到的问题。
流程是这样的：
- 开发人员 A 对 bug 1 进行了一些更改，进行升级。
- 开发者A针对bug 2做了一些修改，升级。
- 开发人员 B 审核开发人员 A 对错误 1 的更改，并将其发回以进行进一步更改。
- 开发人员 C 审核了开发人员 A 对 bug 2 的更改并批准了它，额外升级。
- 开发者A对bug 1做了更多修改，升级。
- 开发人员 C 审查开发人员 A 对 bug 1 的更改。
最后一步是我发现损坏的地方。开发人员 C 无法以任何合理的方式看到与 bug 1 相关的所有更改，即使每个事务/版本（无论 Accurev 如何称呼它们）都与该问题 id 相关联。
如果我根据基础进行比较，我会得到所有 bug 2 的更改以及已升级的所有其他内容。乘以 30 名开发人员，这就是一场噩梦。
如果存在重叠和合并解析，事情就会变得非常混乱，但暂时让我们假设，除非在这种情况下，归因不会出错……即使我看到它不是这样，这可能只是一个误解。
无论如何，假设所有促销都是“干净的”，并且（据我所知）新交易是每个开发人员“保留”交易的“别名”交易。
如何查看两个事务的组合差异？
特别是上面步骤 1 和步骤 5 中的事务。将有两个事务，我只想要这些事务中所做的更改，并且仅这些事务。理想情况下，一个格式良好的或 GUI 工具 diff 可以递归地工作（不是在单个文件上，而是在整个文件上）。
请注意，有效的答案可能是“您做错了”，但应包括有关更改内容的建设性建议，例如“在开发人员的工作区中进行评论”或类似内容。我怀疑我们可能只是错误地使用它。
While I'm not sure I have a satisfactory answer on my other Accurev question, I believe I'm starting to understand the issue I'm seeing with Accurev diffs.
The flow is something like this:
- Developer A makes some changes for bug 1, promote.
- Developer A makes some changes for bug 2, promote.
- Developer B reviews Developer A's changes for bug 1 and sends it back for further changes.
- Developer C reviews Developer A's changes for bug 2 and approves it, additional promotion.
- Developer A makes more changes for bug 1, promote.
- Developer C reviews Developer A's changes for bug 1.
The last step is where I perceive the breakage. Developer C cannot, in any rational way, see all the changes related to bug 1, even though every transaction/version (whatever Accurev calls them) is associated with that issue id.
If I do diff against basis I get all of the bug 2 changes as well as everything else that's been promoted. Multiply that times 30 developers and it's a nightmare.
It gets real messy if there were overlaps and merge resolution, but lets assume, for the moment, that attribution doesn't get wrong except in that case... even if I have seen it do otherwise, it might just be a misunderstanding.
Anyway, assuming that all promotes were "clean" and (as I understand them) new transactions are "alias" transactions of each developers "keep" transactions.
How do I view combined diffs of the two transactions?
Specifically the transactions in step 1 and step 5 above. There will be two transactions, and I want only the changes made in those transactions and only those transactions. Ideally, a nicely formatted or GUI tool diff that works recursively (not on individual files, the whole thing).
Note, valid answers may be "You're doing it wrong," but should include constructive suggestions of what to change such as "Do your reviews in the developer's workspace," or similar. I suspect we might just be using it wrong.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不会说你做错了，但这里肯定需要做出一些假设。就我而言，从您的描述看来，您显然在示例中使用了单个文件（无论如何都是为了简化），并且更改是连续进行的。
在 AccuRev 中，变更包包含与“bug”相关的任何文件的上下文，从基础到头部。因此，当开发人员修复 Bug 1 时，文件的“开始”和“结束”版本都归因于 Bug 1。无论其他 30 个开发人员此时做什么，您始终可以查看 Bug 1 的更改包，查看更改选项卡，并仅比较与该错误相关的文件，即使有一千个额外的更改被提升到该流中。
出现困难的地方在于，开发人员认为他已经完成了，对属于 Bug 1 的文件进行了后续更改，将其链接到 Bug 2，然后继续前进。当审核完成后，他现在必须对 Bug 1 进行其他更改，这些更改将构建在 Bug 2 更改的顶部。
首先，如果您不选择执行“更改包合并”，AccuRev 不会让您升级该文件并将其链接到 Bug 1。这意味着您想要链接到的特定错误的版本归属存在差距 - 特别是对错误 2 的更改。AccuRev 希望您确认这些错误 2 的更改可以隐式包含在错误 1 中使固定。所以我们不会让它偶然发生。但是，如果您决定不希望 Bug 2 的更改出现在 Bug 1 内容中，则必须进行一些修补。在您描述的工作流程下，这会变得更加棘手，但绝对有可能。最重要的是，您所呈现的场景是没有工具能够自动处理的场景，因为存在与不同错误相关的一系列更改。好吧，让我修改一下，没有任何工具可以在“签入评论”之外工作并提供在问题级别而不是文件级别工作的自动化方法。 AccuRev Change Package 功能非常强大，将控制权交给您，让您可以在整个开发过程中将 CP 作为对象进行操作。
我希望这能在这个论坛上尽可能彻底地回答您的问题。如果您还有其他问题或想更深入地讨论，我们也可以安排。
干杯，
〜詹姆斯
I wouldn't say you're doing it wrong, but there are definitely some assumptions that have to be made here. For my part, it seems from your description that you're clearly using a single file in the example (to simplify, anyway) and that the changes are made serially.
In AccuRev, a Change Package contains the context of any file associated with the "bug" from the basis to the head. So when the developer fixed Bug 1, the "beginning" and "end" version of the file are attributed to Bug 1. Regardless of what any of the other 30 developers do at this point, you can always view the Change Package for Bug 1, look at the changes tab, and diff the file only as it pertains to that bug, even if a thousand additional changes are promoted into that stream.
Where the difficulty arises is in the fact that the developer assumed he was done, made subsequent changes to the file that was part of Bug 1, linked that to Bug 2, and moved on. When the review is done and he has to now make additional changes for Bug 1, those are being built on top of the Bug 2 changes.
First of all, AccuRev won't let you promote and link that file to Bug 1 without you choosing to do a "Change Package Merge". This means that there is a gap in the attribution of the versions to the specific bug you want to link to - specifically the changes to Bug 2. AccuRev wants you to confirm that those Bug 2 changes are okay to be implicitly included in the Bug 1 fix. So we won't let it happen just by accident. However, if you decide that you don't want the Bug 2 changes to be present in the Bug 1 content, you have to do some patching. This gets trickier under the workflow you've described, but definitely possible. The bottom line is that the scenario you've presented is one in which no tool is going to be able to automatically handle because there are serial changes associated with different bugs. Well, let me amend that and say that no tool which works outside of things like "check in comments" and provides automated ways to work at the issue level instead of the file level will. The AccuRev Change Package is very powerful and puts the control in your hands, allowing you to operate on the CP as an object all throughout the development process.
I hope this answers your question as thoroughly as possible in this forum. If you have additional questions or want to discuss in more depth, we can arrange that as well.
Cheers,
~James
我认为，在该文件存在多组更改时，在升级这些更改后，无法查看给定开发人员对该文件的更改。
与支持的差异在父级非工作区流中没有任何意义。
差异基础上有每个人的变化。
请参阅接受的答案的评论有什么区别Accurev 中的基础和支持之间的关系。
I believe that there's no way to view a given developer's changes to a file, after those changes have been promoted when there are multiple sets of changes for that file.
Diff against backed has no meaning in a parent, non-workspace stream.
Diff against basis has everyone's changes.
See the comments on the accepted answer of What is the difference between basis and backing in Accurev.