Svn 从以前版本合并（一个“回滚”版本）

我在我的项目的SVN主干中工作，我是唯一的开发者。几天前，我被要求实现一个新的需求，我开始在主干中实现它（顺便说一句，糟糕的选择）：

后来，我被要求修复2.x版本中的一些错误，所以我做了一个测试，并获得了与之前相同状态的下一个版本：

r1156: Reverse merge to recover r1154 state as HEAD.
r1157: Some modifications.

现在我的问题是我想恢复我在r1155中所做的修改。基本上，我想将它们与我当前的主干状态合并。如何实现：

r1158: r1157 code merged with r1155 new features.

---

将1156反向合并到1157上

如果您在

r1157

中修复的错误与您最初在

r1155

中添加的新功能无关，您可以尝试将新功能的代码合并回主干，如下所示：

svn merge -c 1155 TRUNK_URL WORKING_COPY_PATH

这将获取

r1154

和

r1155

之间的差异，并尝试将它们应用于

r1157

之上（假设您的工作副本是最新的）

或者，您可以尝试通过反向合并删除新功能的变更集来“撤消撤消”：

svn merge -c -1156 TRUNK_URL WORKING_COPY_PATH

这将获取

r1156

和

r1155

之间的差异，并尝试将其应用于

r1157

之上（假设您的工作副本是最新的）。

-1156

中的减号非常重要，因为它表示这是反向合并

请注意，这实际上并没有删除

r1156

。您也不会将存储库“恢复”到早期版本

r1156

已提交，因此它将永远留在存储库中，

HEAD

将不再指向

r1156

。您只是简单地将在该修订版中所做的更改应用于您的工作副本，但顺序相反。这是在SVN中进行合并时需要了解的一个关键点

无论哪种方式，如果您在bug修复和新功能中使用了相同的代码位，您可能会遇到合并冲突，您必须手动解决这些冲突。解决所有冲突后，您现在必须将更改提交到工作副本：

svn commit WORKING_COPY_PATH

---

现在

HEAD

将位于

r1158

，您的bug修复和新功能都将在那里

谢谢你的回答。从1156年到1157年的每一个变化都会被删除吗？据我所知，打算进行反向合并。为什么选择1156？使用1155（我想从中恢复代码的修订版）不是更有意义吗？如果您能更详细地解释一下答案，我将不胜感激。@XtremeBiker

r1156

是一项已经承诺的变革。使用这种方法，基本上就是“撤消撤消”；或者，您可以从

r1155

重新应用更改。无论哪种方式，请注意，如果您在错误修复和新功能中使用了相同的代码片段，则可能会出现合并冲突，您必须手动解决这些冲突。@ThisSuitesBlack如果我理解正确，则不太好：我将r1157反向合并到r1156，以便在工作副本中再次获得r1556状态。那么我应该将其与r1155合并以应用3.x更改吗？之后如何恢复1157年的错误修复？真是一团糟：-S@XtremeBiker我认为你不太明白合并的作用。它不会将存储库恢复到以前的状态。合并只是将一个变更集（换句话说，一组差异）应用于您的工作副本。例如，您可以将

r1154

和

r1155

之间的差异应用到位于

r1157

的工作副本上，以“重新添加”您最初在

r1155

中所做的更改。然后，您可以提交更改以获取

r1158

，其中包含错误修复和新功能。请看我的答案了解详细信息。太好了。现在可能是考虑使用发布分支和特征分支来帮助避免未来的好时机。

svn commit WORKING_COPY_PATH