如何自动将更改集成到其他分支

发布于 2024-11-16 03:55:32 字数 615 浏览 1 评论 0原文

我设置了一个自动集成触发器,可以在同一产品内的大约 15 个分支之间进行集成。我的仓库的设置类似于

//Product/dev/main/...
//Product/dev/v1.0/...
//Product/releases/v1.0.0/...
//Product/releases/v1.1.0/...

等。这很容易在之间进行集成。我的触发器对这些仓库路径进行搜索和替换,以从一个路径集成到另一个路径。它通过 Jira 中的子任务获取这些路径。现在其他项目也想要同样的东西。问题在于并非所有项目都遵循相同的结构。有些更像

//ProductB/SubProject/dev/main/...
//ProductB/SubProject/dev/v1.0/...
//ProductB/releases/v1.0.0/...
//ProductB/releases/v1.1.0/...

所以我不能使用相同的搜索和替换方法,因为项目之间可能有所不同。我希望有人能有一个我可以使用的集成技巧。 Branchspecs 对我没有吸引力,因为我们有超过 18 个产品,其中一些产品有超过 15 个分支。因此,如果我为产品创建一个新分支,我必须创建 16 个分支规格。可行,但痛苦。

I have an auto integrate trigger set up that can integrate between about 15 branches, all within the same product. My depot is set up like

//Product/dev/main/...
//Product/dev/v1.0/...
//Product/releases/v1.0.0/...
//Product/releases/v1.1.0/...

etc. That is easy enough to integrate between. My trigger does a search and replace on these depot paths to integrate from one to the other. It gets these paths via subtasks in Jira. Now other projects want the same thing. The problem is not all projects follow the same structure. Some are more like

//ProductB/SubProject/dev/main/...
//ProductB/SubProject/dev/v1.0/...
//ProductB/releases/v1.0.0/...
//ProductB/releases/v1.1.0/...

So I can't use the same search and replace method, because it may be different between projects. I was hoping someone might have a integrate trick I could use. Branchspecs don't appeal to me because we have over 18 products, with some products having over 15 branches. So if I create a new branch for a product, I have to create 16 branchspecs. Doable, but painful.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

过期情话 2024-11-23 03:55:32

如果我理解正确的话,所有 //productB 分支都有一个共同的祖先,对吧?
我认为您可以以编程方式调用 p4 filelog -i 并解析输出以查看它所属的位置。

-i 标志包括继承的文件历史记录。如果文件是由
分支(使用“p4集成”),文件日志列出了
文件的祖先直到导致指定的分支点
修订。通过重命名(使用“p4 move”)继承的文件历史记录是
无论是否指定 -i 都始终显示。

If I understand correctly, all //productB branches have a common ancestor, right?
I think you could programmatically call p4 filelog -i and parse the output to see where it belongs to.

The -i flag includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.

凯凯我们等你回来 2024-11-23 03:55:32

捕获这种高级关系(合并源和目标)必须在分支规范或某种配置文件中捕获。

一旦新的流功能在今年晚些时候推出,两个代码线之间的父/子关系将直接在 Perforce 中捕获,从而使自动合并脚本更容易编写。

Capturing this high level relationship (merge source and target) has to be captured either in a branch spec or a configuration file of some sort.

Once the new streams feature is available later this year, the parent/child relationship between two codelines will be captured directly in Perforce, making an automatic merge script much easier to write.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文