【问题标题】:Why is my reverted file still showing as edited in Code Collaborator?为什么我恢复的文件在 Code Collaborator 中仍显示为已编辑?
【发布时间】:2018-03-11 21:46:24
【问题描述】:

我在 Code Collaborator (CC) 中有一个正在审核的文件,我们将其称为“SomeFile.h”。在第一个版本中,我添加了几行新代码。在第二个修订版中,所有更改都移到了不同​​的文件中,并且 Somefile.h 被还原,因此 SomeFile.h 在最新修订版中应该没有任何更改。

CC 审查摘要页面显示 SomeFile.h:

我希望在CC's Review Summary Screen manual 中看到下表中的“文件已恢复”符号,它似乎不包括实际显示的符号:

此外,如果我单击文件并查看差异,我的旧更改仍会显示,给人的印象是文件未还原。我已经尝试在包含和不包含未更改的 SomeFile.h 的情况下提交更改列表,但它没有效果。

为什么与当前签入的版本相比没有任何更改的文件仍显示第一个修订更改且没有“已恢复”符号?

我的版本控制系统是Perforce,它的服务器版本是P4D/LINUX26X86_64/2016.2/1468155。 Code Collaborator 版本是 9.2.9200。

【问题讨论】:

  • 当我使用 Code Collaborator 时,我通常会发现,如果在我的代码已被纳入审查后对其进行重大更改,那么进行新审查是最容易的。虽然 Code Collaborator 工具非常复杂,可以在一次审核中处理多次代码更改迭代,但 UI 很复杂,审核者经常对结果感到困惑。

标签: version-control perforce code-collaborator


【解决方案1】:

我对 Code Collaborator 不是很熟悉,但我猜测当您“还原”Perforce 中的更改时(请注意,Perforce 中的“还原”一词指的是完全不同的操作,因此使用该词这种方式有点令人困惑)这在 Perforce 中反映为正常编辑,因此它不会在 CC 中显示为特殊的“还原”操作。我进一步猜测,当您在 diff 中看到旧的更改时,它们位于文件的 previous 版本中,因此实际上从当前版本开始,您的更改确实被删除了。

Perforce 确实有一个原生的“撤消”操作,它存储在元数据中,与编辑不同——但是,这是一项新功能(在 2016.2 服务器中添加),据我所知,它不支持命令行以外的任何客户端。 CC 本身可能不会将本地 Perforce 撤消显示为还原,除非它最近已更新。 (如果你是一个命令行用户,它非常漂亮——文件历史将准确显示哪些修订被撤消,你可以配置“集成”命令来考虑撤消操作,这样你就可以重新做撤消的集成,而不是将撤消视为添加新更改的简单编辑)。

【讨论】:

  • 我不使用 Perforce 的命令行——只使用 P4V。对于它的价值,我做了一个实际的还原命令(在 P4v 中),而不仅仅是手动文件编辑。该文件已从更改列表中删除,我重新提交,使我处于当前状态。
  • 哦,那你刚刚得到了一个空编辑。 Perforce 中的“Revert”并不意味着“回滚已提交的更改”,而是“丢弃我的待处理更改”。如果你在 P4V 中“退出”或“回滚”,它会进行编辑,实际上会反转更改(但它不会在历史记录中显示为任何类型的特殊退出操作,在某些情况下它'实际上会弄乱文件的历史)。如果您执行“p4 undo SomeFile.h#=REV”,它将完全退出 SomeFile.h 的#REV
  • 嗯...由于我的更改尚未通过 repo 的审核,我没有意识到我的任何工作都被视为“已提交”。那么有没有办法从 perforce 中说,“回滚之前提交的更改?”
  • 如果你在 P4V 中“退出”或“回滚”,它会进行编辑,实际上会逆转更改(但它不会在历史记录中显示为任何特殊回退操作,在某些情况下它实际上会弄乱文件的历史记录)。如果您执行“p4 undo SomeFile.h#=REV”,它将完全退出 SomeFile.h 的#REV
【解决方案2】:

CodeCollaborator 的文档(特别是您在屏幕截图中显示的符号)已过期。

您在此处显示的屏幕截图:

的已还原文件。从左下角向上扫到左上角的蓝色小箭头是 CodeCollaborator 中的“还原”符号。

此文件仍然出现在您的评论中的原因是有人对其发表了评论。具体来说,某人在该文件的“整体”部分中已“接受”(由带有白色勾号的绿色圆圈表示)。

任何包含 cmets 的文件在评论中仍然可见,即使在被还原后也是如此。这大概是为了防止部分审查讨论因讨论发生的文件被恢复而丢失。 (例如,如果审阅者提出建议重命名文件的问题,这将很常见。)

根据您的用户设置,完全没有没有 cmets 的还原文件可以完全隐藏。所以这可能是你习惯看到的行为。

至于为什么它仍然显示包含您的更改的差异,这似乎是 CodeCollaborator 的设计决定。如主评论页面所示,该文件已被还原,因此其内容在最终更改的上下文中不再具有实际意义。

我同意这可能会造成混淆,因为很容易错过蓝色箭头并认为更改仍然存在。这确实意味着该文件上的任何 cmets,通常是在它处于“已更改”状态时进行的,将保留在最初存在的更改的上下文中。 CodeCollaborator 显示“This file has been reverted”或类似内容而不是 diff 并不是不合理的,但这并不是它的设计行为方式。

【讨论】:

    猜你喜欢
    • 2014-09-23
    • 1970-01-01
    • 2023-03-20
    • 2017-07-24
    • 2016-10-14
    • 2011-04-03
    • 1970-01-01
    • 2020-07-30
    相关资源
    最近更新 更多