Svn 更新到旧版本时，Subversion中存在冲突。问题似乎是我几天前做的一个merge-r。我应该避免这种合并吗？

我已经在Subversion的一个分支上编写代码好几天了。今天我决定更新一个旧版本，就像30年前的版本一样

奇怪的是，我的一个文件中有冲突。我认为这个分支出现问题的唯一原因是，我几天前做了一个

merge-r

，使我（当时）的头脑回到旧版本上

因此，假设问题出在

合并-r

上，我有两个问题：

我进行了-r合并，这样我就可以返回到一个旧版本，然后提交它，这样我就可以从那一点开始工作了（当时我基本上想放弃我最后的X次提交）。做这个-r合并是正确的方法吗？我应该创建另一个分支吗？这当然是我对git的逻辑分支所做的，因为这样会更干净，但我不想用我的分支“淹没”这个颠覆回购。也许我可以用旧版本创建一个分支，然后删除这个分支

假设我现在纠正冲突。回到这个修订版时，我最初的想法是（再次）进行a-r合并。所以如果一周后我决定再回来，我会再次发生冲突，对吗？如何避免这种循环

这个问题也许可以用另一种方式表述。在进行“尝试并出错”编码时（我的意思是我必须“回来”很多次），我应该如何组织我的Subversion repo

---

谢谢

看起来您需要从一个特定版本中分离出一组修改，然后放弃整个版本，然后重新开始，多次。如果是这种情况，那么我建议为每次“尝试”创建一个新分支，并删除整个分支以放弃修改，或者重新集成它，然后在对代码满意时删除它。我认为任何其他方法都会给您带来“合并难题”，但我当然可能错了。

请记住，svn的反向合并不是“回滚并放弃”您的修订，它会将您对这些文件所做的更改撤消到工作副本，直到文件看起来像所需的修订。我从来没有听说过它会产生冲突（除非您的WC中有一个尚未提交的本地修改？）

问题可能是看看冲突是什么，看看你是否能说出冲突出现的地点和原因

使用merge-r是回滚到以前版本的有效方法，但创建新分支也同样有效——这只取决于您如何组织回购以及您拥有多少分支。如果要删除30个修订，那么创建一个新分支并删除旧分支可能会更干净一些

如果你做了大量的尝试+错误编码，DVCS可能是一个更好的选择-git允许你在本地随意多次签入，只向上游推送一个变更集，放弃所有的“尝试”签入（有效地将它们汇总为一个变更），但正如我所说，我们从来没有遇到过回滚问题，即使使用二进制文件，也要查看冲突是什么