更新到旧版本时Subversion中的冲突。 问题似乎是我几天前做的合并。 我应该避免这种合并吗？

Question

我已经在Subversion的一个分支上编写了几天的代码。 今天我决定更新到一个旧版本，埋没了30个版本之前。

奇怪的是，我的一个文件中出现了冲突。 我看到这个分支出现问题的唯一原因就是我几天前做的merge -r - 让我（当时）回到原来的版本。

所以，假设问题是merge -r ，我有两个问题：

1. 我做了-r合并，以便我可以回到一个旧版本，然后提交它，这样我就可以从那时开始工作了（我基本上想放弃我当时的X最后一次提交）。 这样做 - 合并正确的方法？ 我应该创建另一个分支吗？ 这当然是我用git的逻辑分支做的，因为那样会更清洁，但话说再说一遍，我不想用我的分支“泛滥”这个颠覆回购。 也许我可以用旧版本创建一个分支并删除这个？

2. 假设我现在要纠正这些冲突。 回到此修订版时，我最初的想法是再次进行-r合并。 因此，如果在一周内我决定再次回来，我会再次发生冲突，对吧？ 如何避免这种循环？

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

谢谢

Answer 1

看起来你需要从一个特定的修订版中进行一组修改，然后丢弃整套修订版，并重新开始几次。 如果是这种情况，那么我建议为每个“尝试”创建一个新分支，并删除整个分支以丢弃修改，或者重新集成它，然后在您对代码感到满意时将其删除。 我认为任何其他方法都会给你“合并头痛”，但当然我可能错了。

Answer 2

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

问题可能是看看冲突是什么，看看你是否可以分辨它出现的地点和原因。

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

如果你做了很多尝试+错误编码，DVCS对你来说可能是一个更好的选择 - git允许你在本地登记多次，并在上游推送1个变更集，放弃所有'试用'签到（有效滚动）它们变成了一个变化），但就像我说的那样，我们从来没有回滚问题，即使是二进制文件也是如此，因此请查看冲突是什么。