强制如何？在分支之间同步/合并文件
(A) ------- (B) ----------- (C)
| | |
Trunk ReleaseBranch DeveloperBranch
开发人员在 C 分支中工作并签入所有文件。然后修改后的文件将被标记在 C 分支中。部署的二进制文件是从 B 分支构建的 并贴上标签。目前这一切都是手动的。
在 Perforce 中，是否有一种简单的方法可以实现此目的，例如基于标签合并分支等？
(A) ------- (B) ----------- (C)
| | |
Trunk ReleaseBranch DeveloperBranch
Developers work in the C branch and check-in all the files. The modified files are then labeled in the C branch. The binaries that get deployed are built from B branch
and labeled. Currently all this is manual.
In Perforce, is there a simple way to accomplish this like merging Branches based on labels etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
目前尚不清楚您已经拥有多少自动化程度，或者您寻求多少自动化程度。 Perforce 本身提供了跟踪集成和分支的工具，但如果您想做自动化构建和标记之类的事情，您需要将目光投向源代码控制世界之外，进入发布管理/自动化世界。
我假设你有两个分支：
在这些分支内，代码布局大致相似，尽管 dev 比 rel 更新（并且可能有更多错误）。 （你的文字没有解释你在用 trunk 做什么，所以我忽略它。）
假设你正在 dev 中进行开发并且你想发布代码。您可以使用要发布的文件创建一个标签（我们称之为
MYCODE_DEV.1.0）。您可以将其集成到 rel 中：从
MYCODE_DEV.1.0标签集成到发布分支。 Perforce 会跟踪您已合并的文件修订版以及尚未合并的文件修订版，因此它只会合并新代码。如果您对开发中未包含的 rel 进行了更改，则需要解决这些更改（自动或手动）。然后，您可以将更改签入 rel，创建新标签，然后从那里发布。（由于 Perforce 会跟踪您合并的内容，因此如果您尝试再次集成相同的标签，Perforce 将礼貌地拒绝执行任何操作，但如果您认为自己更了解，则可以覆盖它。）
（如果您阅读 Perforce 文档，您会发现对“分支规范”的引用，它允许您声明一个命名分支作为在集成命令中指定源分支和目标分支的简写形式。分支规范对于维护源文件分散在多个分支的复杂分支特别有用。目录，但并没有真正为这里的简单示例增加价值。）
Perforce 为您提供了设置分支和版本以满足您的目标所需的工具，这些工具可以轻松编写脚本，但不能直接执行自动发布。
It's not immediately clear how much automation you already have, or how much automation you seek. Perforce itself provides the tools to keep track of integration and branching, but if you want to do things like automated builds and labeling you'll need to look outside the source code control world into the release management/automation world.
I'm going to assume you have two branches:
Inside these branches the code layout is roughly similar, though dev will be newer (and possibly buggier) than rel. (Your text doesn't explain what you're doing with trunk, so I'm ignoring it.)
Let's say you're devloping in dev and you want to release code. You create a label (let's call it
MYCODE_DEV.1.0) with the files you want to release. You can integrate it into rel with:That integrates from the
MYCODE_DEV.1.0label to the release branch. Perforce keeps track of which file revisions you've merged and which file revisions you haven't merged, so it'll only merge new code. If you've made changes to rel that weren't in dev, you'll need to resolve the changes (either automatically, or by hand). You can then check the changes into rel, create a new label, and release from there.(Since Perforce keeps track of what you've merged, if you try to integrate the same label again, Perforce will politely decline to do anything, though you can override it if you think you know better.)
(If you read the Perforce documentation, you'll find references to "branch specs", which let you declare a named branch as a shorthand for specifying both the source and destination branches in your integration command. Branch specs are especially useful for maintaining complicated branches with source files scattered across multiple directories, but don't really add value to the simple example here.)
Perforce gives you the tools you need to set up your branches and releases to meet your goals, which can be easily scripted, but doesn't directly do automated releases.