TortoiseSVN：使用开关进行合并

我正在同一个中央存储库中与另一个团队合作

他们有一个分支（我们称之为他们的分支），我不允许编辑它（可以查看、签出，只是不能更改）

我有自己的分支机构（myBranch），最初是他们分支机构的复制品。在签出并使用“工作副本”之后，当我对myBranch进行了重大更改时，我会将其提交回myBranch

目标：将他们的分支的任何更改合并到myBranch

第一次尝试-是“合并两棵不同的树”

“此方法适用于您希望合并 将两个不同的分支插入到您的工作副本中。”

结果-代码中的任何差异都被标记为冲突，即使自最初创建myBranch以来代码仅由我更改。另外，由于我从分支中删除了一些仍然存在于其分支中的文件，因此增加了一些复杂性，我遇到了一些树冲突。这棵树对我造成了冲突

问题1： 是否需要手动合并/解决所有树冲突

第二次尝试-使用“切换”将其分支与myBranch合并。切换回我的分支并提交

据我所知，在（2）个不同分支上的同一存储库中工作时，您可以切换工作副本链接到的存储库分支。完成此操作后，工作副本和新分支之间的任何差异将使用“更新”进行“合并”

来自乌龟人：

开关-

正如“更新到修订版”更改工作副本的时间窗口一样 看看历史上的不同点，所以“切换”改变了空间 工作副本的窗口，使其指向工作副本的不同部分 存储库。在处理主干和主干时，它特别有用 只有几个文件不同的分支。你可以换工作 在两者之间复制，并且仅传输更改的文件

更新-

此Subversion命令从 将存储库合并到您的工作副本中，合并其他人所做的任何更改 在工作副本中进行本地更改

结果——在我的工作副本中，任何不同的文件都被该文件的“theirBranch”版本替换

问题2-为什么文件被替换而不是合并

问题3-为什么只存在于其分支中的分支文件被放置在myBranch中，并且没有树冲突

---

请随时回答任何你知道答案的问题或任何关于实现我的目标的建议。谢谢。

首先，这里是对您尝试的分析：
1） 两棵不同树的合并
如中所述，如果：
-您有与myBranch链接的工作副本
-然后在Otteroisesvn窗口中选择merge FROM myBranch TO theirBranch（而不是相反，我想你是这样做的：它解释了你观察到的冲突）。
但是，当没有可使用的合并跟踪功能时，这种合并非常有用，这可能不是您的情况。
2） 切换命令
这不是合并，而是本地工作副本与另一个分支（在您的情况下）的重新同步。因此，如果与切换前的myBranch相比，您没有任何本地更改，那么与切换后的myBranch相比，您将不会有任何更改。正如您所观察到的，这意味着您的本地文件将被替换。这回答了您的问题2和3。
Switch命令不是合并命令，在您的情况下使用它可能非常危险（您最终可能会忘记本地工作副本链接到哪个分支）

---

其次，我建议使用“合并一系列修订”，这似乎非常适合您的情况。但是，仍然可能会遇到树冲突：与所有其他冲突一样，您必须手动解决它们。这就回答了你的问题1。

关于“合并两棵不同的树”（此处未进行改编）和“切换”（根本不是合并！）的定义，你所观察到的似乎非常符合逻辑。我认为您必须使用合并“合并一系列修订”。你试过了吗？洛朗：谢谢你。你说过我的“合并两棵不同的树”的结果是人们所期望的。你能帮我理解为什么我得到了所有的冲突，而没有自动合并？对于切换，虽然它不是一个合并，但根据OttoiseSVN1.7初学者指南：“执行切换不会放弃任何本地更改，它们将在切换时合并。”这让我相信，合并将发生在我的工作副本和我正在切换的分支上，对吗？最后，您建议尝试合并范围，此合并是否会以不同于“两棵树”的方式进行？在执行合并之前，您能否先告诉我，与存储库相比，您的工作副本是否有任何更改？从逻辑上讲，您不应该有任何分支，因为您写道您已经提交了分支上的所有内容。因此，与存储库相比，工作副本将与myBranch（我提交的地方）匹配，但更改将不在其分支中。这就是我想要合并这两个分支的原因。谢谢。通常你不需要“合并两个不同的分支”。它仅用于供应商分支，尤其是如果您使用的是旧的subversion服务器，而该服务器不记录“合并信息”。如果两个分支都包含正确的svn:mergeinfos，那么应该使用

合并一系列修订。否则，手动合并两个分支的独立工作副本可能会更好、更容易。合并可能会变得非常混乱。谢谢你的详细解释，劳伦特！这有助于我的理解，希望其他人也能理解。Àbientôt！