很长一段时间以来，我们所有的开发和部署都是从主干完成的。过了一段时间，这导致生产环境与主干不同步，因为我们收到将新功能“B”移动到生产环境的请求，但推迟了新功能“A”——基本上我们会从主干结帐到临时文件夹，然后有选择地将文件从临时合并到生产（不受版本控制）
在为此挣扎了太久之后，我终于决定重新安排存储库以允许分支，但是在移动（svn mv）主干时犯了一些错误，以便我可以为分支和标签文件夹腾出空间（以前在那里不是“主干”文件夹，文件只是位于项目的父文件夹中），最终结果是我的“主干”现在比我从中创建的一些分支更新。现在我似乎无法从分支合并回主干，而不会丢失很多更改并遇到很多冲突。（我已经从主干更新了分支。）
如果我svn log --stop-on-copy在我的主干上运行，最早的版本是 r14376，如果我在我的分支上运行它，最早的版本是 r14368。（HEAD 位于 r14710）
如何在不丢失 r14368 和 r14376 之间的所有更改的情况下进行正确的合并？我只是要手动合并到主干，但随后我丢失了分支文件的所有修订历史记录。
我玩弄了几种不同的方法来编写合并命令，并认为我终于得到了我需要的东西。我基本上颠倒了合并参数的顺序，以便年轻的主干首先出现，然后是旧的分支，然后我将它们合并到主干的工作副本中：
$ cd trunk
$ svn update
$ svn merge svn://server/project/trunk@14376 svn://server/project/branches/46@14710 .
--- Merging differences between repository URLs into '.':
这仅导致了少数冲突，其中大部分发生在我刚刚接受右侧副本的图像文件上。希望这能让我进入一个未来分支和合并将正常工作的地方。
如果没有看到更多关于你的 repo 的细节很难回答，但也许你可以删除当前的“trunk”文件夹，然后将原始的伪主干（即 repo 根）复制到 HEAD 中的一个主干文件夹中。我认为这将为您提供原始的伪主干作为历史完整的新“主干”文件夹。假设您首先开始修改 rX 中的 repo 根目录，命令将是这样的：
svn rm url/trunk
svn commit -m "Removing broken trunk"
svn cp -rX url/@X url/trunk
svn commit -m "Creating new trunk from previous root"
然后，您可以尝试将分支合并回主干。如果您与主干代码有冲突，请尝试合并所有修订减去您引入主干代码的那些（我假设，也许错误地，您将主干更新作为独立提交进行）。
尽管如此，我还是给了你一个问题，我的声明是你应该知道你在做什么。所以公司里没有人会咕哝说某事不工作，....阅读 svn 书中的合并： http:
//svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge .advanced.advanced语法