我已提交更改集以供审核。不幸的是,我忘了先刷新我的沙箱,所以这意味着我没有在该集合中包含一些更改。
所以我失去了向我的变更集添加更改的选项。
我不想丢弃该更改集,因为它包含重要更改。我也不想交付 2 个变更集,因为它们包含原子逻辑(无法拆分的逻辑)。
我感觉“反向”选项会使我的更改设置回可编辑状态,但我真的不知道该怎么做。
总结一下:我需要让我的变更集再次可编辑,以便我可以将它与另一个合并。
有人知道我会怎么做吗?
Thx,你们统治!
我已提交更改集以供审核。不幸的是,我忘了先刷新我的沙箱,所以这意味着我没有在该集合中包含一些更改。
所以我失去了向我的变更集添加更改的选项。
我不想丢弃该更改集,因为它包含重要更改。我也不想交付 2 个变更集,因为它们包含原子逻辑(无法拆分的逻辑)。
我感觉“反向”选项会使我的更改设置回可编辑状态,但我真的不知道该怎么做。
总结一下:我需要让我的变更集再次可编辑,以便我可以将它与另一个合并。
有人知道我会怎么做吗?
Thx,你们统治!
如果更改集在提交审核之前已“完成”,我认为您无法将更改集恢复到可变状态。
在这种情况下,“反向”(即做一个新的变更集取消先前的变更集),然后是一个新的变更集,您在其中重做您的工作并重新提交以供审查可能是唯一的解决方案。
但是,按照RTC 中的代码审查示例,更改集在审查期间应该是可变的(以便原始程序员根据审查员的反馈签入他的文件的新修订)。
您应该创建新的更改集。
我这么说有两个原因:
1)每个工作项只有一个更改集的美学论点在实践中很快被打破 - 很容易忘记更改,并且您可能由于错误或审查评论而不得不进行修改。
2)拥有多个变更集使您的变更更容易理解。每个变更集可以包含一组逻辑变更,因此单个工作项可能具有三个变更集:“重构代码”、“更新版权”和“审查中的变更”。这样,当有人在未来对文件进行注释时,他们将获得比初始工作项更精细的内容。
关于“原子逻辑”的论点:除非您的团队习惯于交付/丢弃单个变更集,否则这可能不是问题。在 RTC 项目中,我们定期将逻辑上离散的更改拆分为多个更改集和多个组件。
如果您担心您可能会交付逻辑上依赖于其他组件更改的更改集(就像我偶尔做的那样),我建议您加入bug 150421。错误 153907描述了一个类似的问题,但需要一个更复杂的解决方案(使其不太可能在没有客户压力的情况下实施)。
我遇到了同样的问题,并决定创建一个补丁,放弃我的更改,然后创建一个新的变更集。