我在subversion控件下有一个目录。我创建了一个分支，只是为了测试合并的东西。我拿了一个文件，在行李箱中修改了行X为“abc”，并在其分支中修改了与“def”相同的行X.
然后，从分支工作目录我做了：
svn merge branchURL trunkURL .
它更新了文件，内容为该行号的“abc”，即它没有给我一个与svn update给出的相同行号的冲突，如果我在同一行中完成的话工作目录，有人在存储库中提交了“def”。
那么svn merge只是在合并时替换内容而不会引起任何冲突吗？
如果是这样的话，当一个人不能以某种方式合并以便保持主干和分支的变化时，从主干分支出一个proj dir的原因就没用了。
答案 0 :(得分：6)
你确实意识到了什么
svn merge branchUrl trunkUrl branchWorkingCopy
实际上是吗，是吗？
这是翻译：
找出使 branchUrl 的内容与 trunkUrl 的内容相同所需的一组更改。现在在 branchWorkingCopy 上执行这些更改。
您不会以这种方式合并任何冲突。但是，当您签入 branchWorkingCopy 时，您的分支将与您的主干相同，这几乎肯定不是您想要的。
如果您只想将选定的更改从 trunk 复制到分支，则需要告诉Subversion 要复制哪些更改并使用不同形式的合并命令：
svn merge -r100:103 trunkUrl branchWorkingCopy
这意味着：确定从主干上的r100到r103所需的一组更改。在工作副本（分支）上执行这些更改。请注意，此“更改集”不会包含r100所做的更改，因为这些更改是从 r99 到r100所需的一组更改所捕获的。 Subversion中的修订范围半开。
此外，如果您还没有，请考虑阅读fine manual。
答案 1 :(得分：0)
svn merge刚刚替换 合并时的内容，而不是 带来任何冲突？
嗯，不。我无法确定你做错了什么，但合并标志与更新相同。
答案 2 :(得分：0)
我可能会遗漏一些东西，但是当我使用svn merge时，如果我希望它能正常工作，我总是必须得到正确的版本号。
因此，如果您在修订版100中分支（或上次合并），则主干当前为200，并且您希望将更改从主干合并到您的分支中，然后在分支工作目录中：
svn merge -r 100:200 trunkURL
然后我认为你会看到一个冲突，你解决并签入。你在trunk工作目录中做了类似的事情，从你的分支合并回到trunk。
没有-r的svn merge会对您指定的两个位置进行区分，并将该diff应用于工作目录。所以我推测发生的事情是没有冲突，因为你的工作目录与分支机构的负责人相匹配。因此，分支头部和主干头部之间的差异可以毫无问题地应用于您的工作目录。这不是你想要做的：它只是改变你的工作目录以匹配主干。尝试在分支上进行另一项更改，签入并重复此过程。如果合并撤消了更改（因为它不在主干上），那么我对这种形式的svn合并是正确的，但正如我所说我还没有使用它。
[编辑：在svn版本1.5之前...]
工作目录和分支在SVN中不是一回事，虽然很烦人，但你必须考虑到差异。 SVN需要更多信息来进行您想要的分支合并，而不是进行更新或签入，因为afaik并不会自动考虑分支发生的位置，因为它总是考虑工作目录的签出位置。我确信这是有原因的，我只是不确定它是什么：可能是因为svn copy不仅仅是分支。
[编辑...但是根据Joshua McKinnon对此答案的评论，从1.5 svn开始支持正确的分支合并，它会自动执行您想要的操作。指定要合并的URL，并在工作目录中运行您要合并的任何命令。所以在这种情况下，请尝试
svn merge trunkURL
你应该看到冲突。您可能必须先恢复工作目录。]