在 RTC 源代码控制中合并两个流答案

【问题标题】：Merging two streams in RTC source control在 RTC 源代码控制中合并两个流
【发布时间】：2013-10-23 11:06:09
【问题描述】：

我有两个流：sA 和 sB

sB 是从 sA 创建的，因为 sB 中的更改集不包含在 sA 中。两个并行的开发流程正在进行中：sA 和 sB

现已在 sA 上完成开发。 sB 包含不在 sA 中的变更集。

sA 和 sB 将被合并，以便 sA 中的变更集包含在 sB 中，但 sB 中的变更集不包含在 sA 中。

这就是我认为合并应该发生的方式：

每个从事 sA 工作的开发人员都将他们的流量目标更改为 sB。
每个开发人员将他们的变更集交付给 sB。

sB 现在保持独立并包含不在 sB 中的更改集，但也包含在 sA 中的所有更改集

这是一种有效的方法吗？

我能否将更改集交付给其他开发人员创建的流，如果可以，这意味着每个开发人员不必像我可以为他们那样交付他们的流？

【问题讨论】：

标签： version-control rtc

【解决方案1】：

它在技术上是“有效的”，但我更喜欢“拉”的方法：

一个集成商在sB 上创建了一个repo 工作区。
流目标更改为sA，以便接受来自sA的更改集。
流目标恢复为sB。
他/她在他/她的本地工作区合并，签入，放置基线，然后交付给sB。

这使得sA 的开发人员只需担心交付给sA，而不用关心sB。

【讨论】：

这是否意味着一个人负责合并/交付给 sB ？ “他/她在他/她的本地工作空间中合并、签入、放置基线，然后交付给 sB。”换句话说，您的意思是“来自 sA 的所有更改集都合并到 sB 存储库工作区，创建 sB 的快照，然后将更改集交付给 sB”？此外，“签入”作为“他/她在他/她的本地工作空间中合并、签入、放置基线并交付给某人”的一部分发生在哪里。 ?
@user470184 1/ 不一定：您可以要求每个 devA 在 sB 上创建一个 repo 工作区，并从 sA 接受他们的更改集。它仍然是一种“拉动”方法，但这一次，分布在来自 sA 2/ 的开发人员中，只要合并导致本地修改，就会发生签入，将修改后的文件留在仓库工作区的“未解决”部分（在“待处理”中）改变”视图）。
我认为每个开发人员更容易将流目标更改为 sB 并将更改集从 sA repo workspace 重新交付给 sB。我认为这与您的方法相似，只是在您的方法中，从 sB 创建了一个新的 repo 工作区，并且 sA 的更改集被 sB 接受。使用您的方法似乎使合并复杂化，但也许我没有完全理解原因。我认为您的方法的优势在于它允许一名开发人员代表在 sA 中具有更改集的其他开发人员将所有更改集交付给 sB。
@user470184 我理解并尊重你的方法，但我的观点一直是：如果你有一个流的 repo 工作区，你应该只做与那个流相关的工作。通过将流目标从 sA 的 repo 工作区更改为 sB，devA 将无法将更改集从 A 传递到 sB，除非他/她首先接受从其他 devsA 传递到 sB 的其他更改集乙>。他/她会接受最初为在 A 上工作而完成的 repo 工作区中的那些。这不好。如果您将内容合并到 sB，请使用为 sB 完成的 repo 工作区。
@user470184 通过拥有专用于 sB 的 repo 工作区，devA 将接受来自 sA 的他/她的更改集，并将这些更改集合并到由 sB 源制成的本地沙箱中。然后他/她可以交付给某人。第二个 devA 将能够做同样的事情，同样在由 sB 源创建的本地工作空间中，接受和合并来自 sA 的更改集。 在离开为 sA 制作的本地工作区（即为 sA 进行日常开发工作的地方）的同时，保持原样。