我已经在Subversion的一个分支上编写了几天的代码。今天我决定更新到一个旧版本，埋没了30个版本之前。
奇怪的是，我的一个文件中出现了冲突。我看到这个分支出现问题的唯一原因是几天前我做的merge -r让我（当时）回到原来的版本上。
因此，假设问题出在merge -r，我有两个问题：
我做了-r合并，以便我可以回到旧的修订版然后提交它，这样我就可以从那时开始工作了（我基本上想放弃我的X最后一次提交时间）。这样做 - 合并正确的方法？我应该创建另一个分支吗？这当然是我用git的逻辑分支做的，因为那样会更清洁，但话说再说一遍，我不想用我的分支“泛滥”这个颠覆回购。也许我可以用旧版本创建一个分支并删除这个分支？
假设我现在要纠正这些冲突。回到此修订版时，我最初的想法是再次进行-r合并。因此，如果在一周内我决定再次回来，我会再次发生冲突，对吧？如何避免这种循环？
这个问题也许可以用另一种方式表达出来。在进行“尝试和错误”编码时（我的意思是我必须多次“回来”），我应该如何组织我的Subversion回购？
由于
答案 0 :(得分：1)
看起来你需要从一个特定的修订版中进行一组修改，然后丢弃整套修订版，并重复几遍。如果是这种情况，那么我建议为每个“尝试”创建一个新分支，并删除整个分支以丢弃修改，或者重新集成它，然后在您对代码感到满意时将其删除。我认为任何其他方法都会给你“合并头痛”，但当然我可能错了。
答案 1 :(得分：1)
请记住，svn的反向合并不是“回滚并丢弃”您的修订版，它会将您对这些文件所做的更改撤消到工作副本，直到文件看起来像所需的修订版。我从来没有听说过它会产生冲突（除非你的WC中有一个本地修改但尚未提交？）
问题可能是看看冲突是什么，看看你是否可以分辨它出现的地点和原因。
使用merge -r是回滚到先前版本的有效方法，但创建新分支同样有效 - 这仅取决于您如何组织回购以及拥有多少分支。如果您要删除30个修订版，那么创建新分支并删除旧分支可能会更清晰。
如果你做了很多尝试+错误编码，DVCS对你来说可能是一个更好的选择 - git允许你在本地登记多次，并只在上游推送1个变更集，放弃所有'试用'签到（有效地将它们分成1个变化），但就像我说的那样，我们从来没有回滚问题，即使是二进制文件也是如此，所以请看看那个冲突是什么。