如何查看 Perforce 中的分支是否包含错误修复？
（我是一个新的 perforce 用户，但过去使用过许多其他源代码控制系统。）
我们使用更改列表来签入每个错误修复；更改列表注释包含错误 ID，因此可以轻松跟踪错误修复何时签入分支。
但是，我看不到一种简单的方法来查找给定错误修复已合并到的所有分支，或者查找已合并到给定分支的所有错误修复。
据我所知，perforce 不会跟踪更改列表已合并到的所有分支。据我了解，当合并完成时，历史记录不会复制到目标分支中，因此合并完成的更改列表上的注释中目标中的唯一历史记录。
我缺少什么？
(I am a new perforce user, but have used lots of other source code control systems in the past.)
We use a change list to check-in each bug fix; the change list comment includes the bug ID therefore it is easy to track when a bug fix has been checked into a branch.
However I can’t see an easy way to find all branches a given bug fix has been merged into, or to find all bug fixes that have been merged into a given branch.
As far as I can tell perforce does not track all the branches a change list have been merged into. As I understand it, when a merge is done in perforce the history is not copied into the target branch so the only history in the target in the comment on the change list the merge was done into.
What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Perforce 跟踪文件修订版本的集成位置，但它不会自动将签入注释与错误跟踪元数据一起传播。
给定特定分支上的变更列表，您可以通过要求 Perforce 集成变更列表来判断 Perforce 是否认为变更列表已被集成。 （我在更传统的源代码控制意义上使用“分支”，表示源代码树的特定分支，而不是在特定的 Perforce 意义上使用“分支”来表示这两个源代码树之间的集成路径。）假设您一直在
//source/project/trunk/...中工作，并且您有一个变更列表 @1234，您想检查它是否已集成到您的发布分支中//源/项目/rel/...。创建一个映射//source/project/rel/...的客户端并执行：如果 Perforce 告诉您“所有修订版本已集成。”，则变更列表 @1234 已集成，并且错误修复应该在发布分支上可用。如果 Perforce 列出已更改的文件，则这些文件尚未集成。 （也有可能集成变更列表中的某些文件而不是其他文件，这可能会导致一些有趣的问题。）
这并不能很好地扩展——您需要检查您关心的每个分支上的每个错误修复，尽管它确实适合自动化。
您可以使用“不受支持的”Perforce 命令
interchanges来快速了解哪些变更列表尚未从一个分支集成到另一个分支中。 （用 Perforce 的说法，“不受支持”意味着“在下一个版本中可能不会同样工作，但我们认为它可能有用，所以我们无论如何都会发布它”。）查看哪些变更列表尚未从我们的版本中集成例如 trunk 到发布分支，执行：在这个例子中，我没有列出changelist @1234，因为它已经被集成到发布分支中。我在使用 interchanges 时遇到的一个问题是，它会在未集成的更改之后列出每个较新的修订版，即使较新的修订版本身已被集成，因此如果您正在为某个版本挑选修订版分支，您可能会看到更改列表再次列出。我首先使用
交换来大致了解需要集成的内容，然后查看集成以更好地了解真正缺少的内容。（Perforce 还支持类似的“作业”概念，允许人们将特定的修复附加到特定的变更列表，但我的组织不使用它们，所以我不知道它们的工作效果如何，也不知道它们是否在集成时自动传播。）
Perforce tracks where revisions of a file have been integrated, but it doesn't automatically propagate check-in comments with your bug-tracking metadata.
Given a changelist on a particular branch, you can tell whether Perforce thinks the changelist has been integrated by asking Perforce to integrate the changelist. (I'm using "branch" in the more traditional source-control sense, to mean a particular branch of the source code tree, rather than in the specific Perforce sense to mean the path of integration between these two source code trees.) Let's say you've been working in
//source/project/trunk/...and you have a changelist @1234 that you'd like to check whether it's been integrated into your release branch//source/project/rel/.... Create a client that maps//source/project/rel/...and execute:If Perforce tells you "All revision(s) already integrated.", changelist @1234 has been integrated, and that bugfix ought to be available on the release branch. If Perforce lists files that have changed, those files have not been integrated. (It's also possible for some files in a changelist to be integrated and not others, which may make for some interesting problems.)
This doesn't scale especially well -- you need to check each bugfix on each branch you care about, though it does lend itself to automation.
You can use the "unsupported" Perforce command
interchangesto get a quick idea of what changelists have not been integrated from one branch into another. (In Perforce parlance, "unsupported" means something like "might not work the same in the next revision, but we think it could be useful so we'll release it anyway".) To see what changelists haven't been integrated from our example trunk to release branches, execute:In this example, I haven't listed changelist @1234 because it's already been integrated into the release branch. One problem I've experienced using
interchangesis it'll list every newer revision after an unintegrated change, even if the newer revisions themselves have been integrated, so if you're cherry-picking revisions for a release branch you may see changelists listed again. I useinterchangesas a first pass to get a rough idea of what I need to integrate, then look atintegrateto get a better idea of what's really missing.(Perforce also supports a similar concept of "jobs", that let one attach particular fixes to particular changelists, but my organization doesn't use them so I don't know how well they work or whether they are propagated automatically on integration.)