SVN 分支到主干合并问题

Posted 2023-02-19

【中文标题】SVN 分支到主干合并问题

【英文标题】：SVN Branch To Trunk Merge Issue

【发布时间】：2015-03-28 04:17:27

【问题描述】：

我已经尝试用谷歌搜索手头的问题，但无济于事。我的团队处于一个有趣的境地。

我们的发布分支需要合并回我们的主干。在大约 4 周的提交之后，没有人这样做（我们通常尝试每周进行一次）。然后开发人员将分支合并到主干，但只做了一系列修订，不包括分支的所有修订。

示例：我们在提交 1000 处创建了分支。提交 1000-1400 都发生在第一次合并之前。开发人员合并了提交 1300-1400。一直以来，也有对主干的承诺。

又过了一两个星期，现在我们要提交 1500。我们去进行另一个合并，当然，一切都失败了；我们不需要大量的提交来构建通过（提交 1000-1300）。我们无法完全恢复，因为我们冒着毁掉整个期间对主干所做的所有更改的风险。

我们有哪些选择？这是一个关键的合并，因为我们的主要版本即将发布；我们需要在相对较短的时间内尽可能减少搞砸的机会。

【参考方案1】：

天哪，这听起来很乱……

首先要做的是将所有开发人员从 repo 中踢出几个小时，如果不是几天的话（因为这需要一段时间并且压力很大，希望你周末没有计划......） ，也许也让您的 CI 系统离线一段时间。 （不是必要的，但它会保存一堆损坏的构建）

然后阅读：SVN Manual for dump/load

为您的 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 包的一部分）的简洁工具可以帮助您缩短此过程。一点点/试着看看造成的混乱。 )

如果您在任何阶段搞砸了，请将“旧”回购移到新位置，并将您的回购备份的副本放在旧回购的位置。

祝你好运！！！！。

【讨论】：

我接受了您的回答，因为在更糟糕的情况下，我相信这将是一个不错的选择；但是，我们非常幸运能够恢复合并并将分支中的所有内容重新集成回来，而不会发生任何故障。 8.5 小时和几盒比萨饼，我们很高兴我们的发布:)。感谢您的回答！

那是幸运的，我回答的唯一原因是因为我实际上有一个类似的问题，我个人必须处理，除了我们的问题包括很多文件重命名和重新组织，在破坏由于 dos 和 unix 行尾的不同，分支和空白会发生变化。