由于 SVN 存储库管理不善，我们最终创建了一个名为 Stable 的分支，其中包含代码的稳定版本（该分支实际上是从上一个版本的标签开始的，而不是从主干开始）。
基本上，主干已经被我们的新程序员所做的一些更改“感染”了，他们并不真正知道自己在做什么。
我想要实现的目标是使稳定分支成为主干，放弃自分支发生以来的所有这些更改，但是我需要确保保留分支前的所有历史记录。
分支是否包含分支发生之前的所有历史记录？ （在这种情况下，我认为我可以将分支移动为主干？）
我能找到的所有教程都在谈论合并..但我对此感到紧张，因为如果我的理解是正确的，如果主干中发生了变化不会发生冲突，我最终会在稳定版本中得到这些。
那么问题是，对于这种情况，我的最佳选择是什么？
预先感谢您的意见！
Due to some mismanagement of our SVN repository, we ended up making a branch, named Stable, containing a stable build of our code (the branch actually got started from a tag of the last release, rather than the trunk).
Basically trunk has been 'infected' by some changes made by our new programmer, who didn't really know what they were doing.
What I want to achieve is making the stable branch the trunk, discarding all these changes since the branch occurred, however I need to make sure I preserve all the history pre branch.
Does the branch contain all the history prior to the branch occurring? (in which case I think I can just move the branch to become the trunk?)
All tutorials I can find talk about merging .. But I'm nervous about that because if my understanding is correct, if there are changes in trunk that do not happen to conflict, I would end up with these in the stable build.
So the question is what is my best option for this situation?
Thanks in advance for your input!
发布评论
评论（4）
在您的情况下，我建议使用合并回滚主干上的更改。您可以使用主干作为合并的源和目标，以与合并命令相反的顺序指定修订号。例如，在 trunk 的工作目录中（请注意，您可能更喜欢使用存储库 url）：
将回滚从修订版 X 到修订版 Y 所做的更改。另请注意，svn merge 命令有一个 --dry-run选项，以便您可以在实际进行任何更改之前验证将要执行的操作。
请记住，使用版本控制的原因之一是可以保留更改的历史记录并在必要时回滚它们。即使您现在不这么认为，主干上的错误提交也可能是您将来想要参考的内容。
In your situation, I would recommend rolling back the changes on your trunk using merge. You can specify the revision numbers in the reverse order to the merge command using the trunk as both the source and destination for the merge. For example, in the working directory for the trunk (note that you may prefer to use the repository urls):
will roll back the changes made from revision X to revision Y. Also note that the svn merge command has a --dry-run option so that you can verify what will be done before actually making any changes.
Remember that one of the reasons that you use version control is so that you can keep a history of your changes and roll them back if necessary. Even if you don't think so now, the erroneous commits on the trunk are maybe something that you will want to refer to in the future.
是的，分支包含复制之前的所有历史记录...因此您可以删除当前的主干，然后将分支复制或重命名为主干，然后就可以开始了。
来自 svn log --help ：
Yes, the branch contains all of the history prior to the copy... so you can just delete your current trunk, and either copy or rename your branch to trunk and you should be good to go.
From
svn log --help:有几个选项：
您可以移动您的目录在 SVN 中，就好像（几乎）您正在组织本地目录一样。所有的历史都将被保留。 （当然包括您的“移动”）
如果你想让存储库进入这样的状态，这个错误不会出现在历史记录中，那么你可以使用 管理功能删除不需要的变更集并手动添加它们到适当的地方。这可能很乏味，并且如果在其他地方引用了修订号，您可能必须查看修订号。
同时，我建议与团队一起决定策略，以便避免了混乱。
There are a few options:
You can move your directories in SVN as if (almost) you are organizing your local directories. All the history would be retained. (which would include your 'move's of course)
If you want to bring the repository into a state where this mistake won't be in the history, then you can use the administration features to remove the unwanted change-sets and add them manually to the appropriate place. This might be tedious and you might have to look into your revision numbers if they are referenced elsewhere.
In the mean time I suggest deciding on a strategy with the team so confusions avoided.
我喜欢你描述这位程序员的变化的方式。因此，如果：
，您可以尝试非常仔细执行
svnadmin dump -rX： Y转储存储库直至受感染的版本，删除当前存储库，并使用未受感染的版本恢复它。I loved the way you described the changes of this programmer. So, if:
you could try very carefully to do a
svnadmin dump -rX:Yto dump the repo until the infected revision, erase the current repo, and restore it with the not infected one.