Merge 如何找出一个变更单的原始来源

实际上，我们做了很多分支和合并。我们如何找到引入了一个变更的原始变更列表

例如，我在自己的私人分支中提交了一个id为53343的变更列表，两天后，它被合并到公司分支a，然后一周后，它被合并到集成分支B，最后，它被合并到主分支。 现在变更列表id是一个完全不同的id，比如55445，因为它是一个合并，它实际上包含了很多变更列表，除了我的变更列表，可能有300个

我现在怎么才能拿到原版的“53343”

下面是更详细的描述

例如，我想知道仓库范围内一个文件的更改历史

$ p4 changes //prod/main/platform/abc.txt
Change 560938 on 2017/04/13 by user1@user1:main 'bug fix2'
Change 559384 on 2017/03/24 by user1@user1:main 'bug fix1'
Change 559178 on 2017/03/22 by branchowner@branchowner:ws 'Merge Integration@558992 to main '

我们可以在主分支中看到它来自一个合并。 并使用注释

$ p4 annotate -I //prod/main/platform/abc.txt
.
.
.
554294: Monday morning
554294: I love foot ball
554294: XNES rocks
.
.
.

我们可以看出，变化首先来自554294

$ p4 describe 554294|more
Change 554294 by user2@user2:coorA on 2017/01/17 19:24:51
Integrate  all dev changes to coorA 

Affected files ...

.
.
.
... //prod/coorA/platform/abc.txt#1 add
.

554294是一个合并，在此合并中，添加了文件abc.txt。但事实上，这个abc.txt不是在这里创建的。 我在我的开发分支中创建了这个abc.txt，但分支管理员从我这里复制了它，并在他的分支中进行了“p4添加”。所以，现在对于主分支，只能看到文件abc.txt是来自coorA分支的原始文件。 我们失去了这个文件的真正第一个所有者，我们只能追查到分支管理员

---

我们现在想要的是获得原始所有者，但当它添加到coorA branch中时，我们失去了关系，是否还有更深入的追溯，例如，通过文件md5sum？

我假设您正在查看特定文件中的更改。在P4V中找到该文件，单击鼠标右键，然后选择“修订图”。这将向您显示更改如何传播的图表。图中的每个节点都是文件的一个版本。合并显示为箭头（边），因此向上增加错误将使您从55445增加到53343

---

此外，要快速查看文件不同版本之间的更改，您可以将图形的一个节点拖放到另一个节点，P4V将显示差异。

正如您所说，更改55445可能包括来自许多不同分支的大量更改。您可以通过运行以下命令查看所有内容：

p4 changes -i @55445,55445

但是，当你说你试图获得一个更具体的“变更”的来源时，我认为你所问的是变更55445中的一个特殊差异，即在一个特定文件中有一个特定的行，你试图找到它的来源。为此，请运行：

p4 annotate -I //depot/file

p4 annotate

命令显示该文件中每行的修订/更改；

-I

标志跟踪合并关系，以找到跨不同分支的每条线的真实原点

---

资料来源：几年前我写的博客文章

谢谢你的帮助。我的情况有点不同，可能是因为使用性能错误。在我的案例中，我的变更列表正在添加几个文件，从我的私人分支机构->公司分支机构A，分支机构所有者在公司分支机构A中使用“p4添加”这些文件，这些文件是从我的私人分支机构复制的，所以即使是从“p4注释”中，最初提交的文件在公司A分公司……我不太清楚——如果这些文件是在A分公司中添加的全新文件，它们与您的分公司中的更改有什么关系？无法将所有内容都放在评论中，我将不得不编辑问题，以显示我的问题“分公司管理员”在您的示例中，您应该学习如何分支文件，而不是手动复制并添加它们：如果历史记录中没有文件相关的记录，则无法按照关系构建查询。谢谢，是的，这在大多数情况下都有帮助。我的情况有点不同，可能是Perforce的用法不对。如上所述。如果“分支管理员”在未告知Perforce文件已被复制的情况下手动复制了文件（即，未使用

p4 copy

或

p4 integrate

），您就无法合理地期望Perforce通过魔法找出这些文件的来源。