我已经尝试用谷歌搜索手头的问题，但无济于事。我的团队处于一个有趣的境地。
我们的发布分支需要合并回我们的主干。在大约 4 周的提交之后，没有人这样做（我们通常尝试每周进行一次）。然后开发人员将分支合并到主干，但只做了一系列修订，不包括分支的所有修订。
示例：我们在提交 1000 处创建了分支。提交 1000-1400 都发生在第一次合并之前。开发人员合并了提交 1300-1400。一直以来，也有对主干的承诺。
又过了一两个星期，现在我们要提交 1500。我们去进行另一个合并，当然，一切都失败了；我们不需要大量的提交来构建通过（提交 1000-1300）。我们无法完全恢复，因为我们冒着毁掉整个期间对主干所做的所有更改的风险。
我们有哪些选择？这是一个关键的合并，因为我们的主要版本即将发布；我们需要在相对较短的时间内尽可能减少搞砸的机会。
【问题讨论】：
标签： svn version-control branching-and-merging
天哪，这听起来很乱……
首先要做的是将所有开发人员从 repo 中踢出几个小时，如果不是几天的话（因为这需要一段时间并且压力很大，希望你周末没有计划......） ，也许也让您的 CI 系统离线一段时间。 （不是必要的，但它会保存一堆损坏的构建）
为您的 repo 文件系统制作一个备份副本。 （以防你犯了错误。）
svnadmin dump REPO_LOCATION_HERE --revision 0:LAST_SAFE_REVISION_NUMBER_HERE > baseline.dumpfile
创建另一个 repo，并“加载”您的转储文件
svnadmin load --force-uuid /opt/subversion/my_new_repo < baseline.dumpfile
现在回到你的旧仓库，
svn log -r LAST_SAFE_REVISION_NUMBER_HERE:HEAD REPO_LOCATION_HERE > reading.txt
通过 reading.txt 并手动写下提交到主干的“有效”且需要保留的内容（几乎是第一次合并之前的所有内容。），然后手动将它们转储/加载到新的使用上述方法repo。
现在重新做第一次合并（这次一定要包含分支中的所有修订。）
这是有趣的部分，从第一次合并到第二次合并后立即执行 svn log --diff。手动使用 linux 'patch' 命令将文件一个接一个地修补到新的 repo 中。对于“狡猾”的 100 次左右的提交，然后 svn 转储/加载剩余的好提交（假设有任何提交。）
最后从你的新仓库中进行一次完整的检查，运行你所有的测试。如果他们通过了，则将旧 repo 移动到新位置，并将新 repo 移动到旧 repo 的位置。并告诉你所有的开发人员做一个干净的结帐，你应该很好。
有一个名为 tkdiff（tkcvs 包的一部分）的简洁工具可以帮助您缩短此过程。一点点/试着看看造成的混乱。 )
如果您在任何阶段搞砸了，请将“旧”回购移到新位置，并将您的回购备份的副本放在旧回购的位置。
祝你好运！！！！。
【讨论】：