Perforce 难以组织Performce streams以容纳多个具有流的主分支

因此，我们有一个项目，其中有多个“主要”分支正在同时工作。所以有1.0.0、2.0.0和3.0.0。进入2.0.0的东西不能进入1.0.0，以此类推。每个分支向前合并，1.0.0>2.0.0>3.0.0

我不认为我们可以使用正常的流，因为如果我们设置发布分支，你就无法从中获得功能分支，而且这些分支还不是“发布”，它们仍在积极开发中。如果我们走到下面，那么所有的东西都必须通过一个主要分支才能发布，并且没有办法隔离文件

所以我想我的问题是，有没有一个合适的方法来为这样的东西设置流

谢谢

---

关于主线模型使用的许多假设都来自于一个环境，在这个环境中，版本被裁剪的频率相对较低（一年两次），并且只针对关键的bug进行修补——因此需要从一个版本到另一个版本的更改往往是例外，而不是常规。在这个模型中，绝大多数合并仅仅来自最新版本（例如，当版本稳定时，在该版本之前的版本中几乎没有活动），或者从开发分支返回到主线，从主线返回到开发分支（因为开发分支主要致力于开发面向主线的新功能，而不是任何发布分支）。只有在手动挑选这些功能以解决关键错误时，才会将它们从主线更改为发布分支（这是很少见的），并且从不直接从开发分支到发布分支。从旧的发布分支到一堆以后的发布分支，选择一个补丁有点尴尬，但在这个模型中很少出现，所以尴尬并不重要

如果您同时非常积极地处理多个版本，那么主线模型的价值就会降低，因为您需要：

• 在同级/同级分支之间进行合并（大多数情况下可以正常工作，但如果进行了大量重构，则可能会变得笨拙）
• 仔细挑选主线之间的变更，以实施正确的变更流程（这有助于更干净的合并，但需要更多的手动跟踪）

这里的传统建议可能是重新考虑您的发布方法/策略，不需要太多的“水淹”，但我假设您有商业理由要求它以这种方式工作。鉴于这种限制，我认为您可能不想使用不同流“类型”和“流”的概念因为这些都是关于内置主线模型的假设，而您所做的根本不是主线开发模型

要在streams中实现一个非主线模型（在没有流管理指南的情况下仍然有一些价值，因为它将帮助您管理客户端视图等等），您可能需要使用以下组合：

• 使初始主线之后的每个流都成为

  开发
  流（我认为这是最允许的）

• 在每个流中设置

  mergeany

  选项（该选项允许在所有方向上进行合并，而不是试图强制执行作为主线模型概念的“稳固性”）
• 合并时使用

  -F

  选项忽略流向（我认为

  mergeany

  如果您一直使用它，则不需要此选项）

---

谢谢你的详细解释！看看你的建议，我想我有一些东西应该可以用。基本上，“主”流并没有真正用于任何事情，但开发流是基于此创建的，并插入到最新的流之间。