我们有一个补丁模型，我们打算使用cset.pl -findmerge <activity>有选择地将累积活动合并到补丁流（集成流到集成流）。请注意，我们使用的是单个流模型;虽然支持使用自己的开发流程的团队支持（即当他们加入项目时，他们将默认使用集成）。
然而，我们正试图解决的是活动依赖问题。
所以说你有integration stream A，
file a.txt
-> Change 1 (baselined ReleaseA)-> Change 2 -> Change 3
fileb.txt
-> Change 1 (baselined ReleaseA)-> Change 2
集成流B和配置。经理决定他们想在新补丁中包含“Change 3”（补丁整合流 - 整合流C）
他们针对cset.pl fetchmerge执行了Change 3（其中包括Change 2的更改）
Change 2的{{1}}未被提及，因此问题是识别这些活动依赖关系。
有人有什么想法吗？
答案 0 :(得分：0)
如果Change3是rebase / deliver活动，您可以使用
%ct lsact -contrib Change3
获取贡献活动列表
然后遍历任何列为贡献的rebase / deliver活动
跟踪其中任何一方是否有Change2作为贡献活动的活动。
另外，假设补丁流的基础基线是用于RelaseA的基准线，那么在进行合并时，是否需要列出Change1以后的活动？
即你的findmerge调用不应该像
%findmerge ... Change2,Change3 -fcsets ...
答案 1 :(得分：0)
注意（除了sateesh's answer）之外，deliver -act Chaange3（而非查找合并）会将Change2和Change1列为要在您的投放中包含的活动。
它会接受那些依赖的活动，可能遵循接近sateesh描述的算法。
答案 2 :(得分：0)
必须使用各种cctool命令查看视图中的当前版本并将其推送到脚本中以获取活动依赖项列表
