如何在 svn 中正确地进行提交后分支并恢复主干？
我有一些提交，事后决定，将更多地进行分支工作，而不是主干工作。 如何创建分支并恢复主干，同时仍然确保以后合并不会很痛苦？
是否像将当前主干复制到分支并恢复主干一样简单？ 或者这会造成以后的头痛吗？
I have some commits that I've decided, after the fact, are going to be more branch work then trunk work. How do I create the branch and revert the trunk while still ensuring merging isn't painful later?
Is it as simple as copying the current trunk to a branch and reverting the trunk? Or will this create headaches later?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为飞利浦的方法将类似于以下内容，假设最后一个“良好”修订版本为 100，而您现在为 130，创建新分支：
请注意，想法是保留在这些修订版本中所做的更改，以便您可以应用他们回到后备箱。
恢复主干：（
执行这些操作的顺序并不重要，因此您可以在创建分支之前恢复主干。）
然后您可以切换到在存储库中创建的新分支：
I think Philips method would be something like the following, assuming the last "good" revision was at 100 and you are now at 130, to create the new branch:
Note the idea is to preserve the changes made in those revisions so you can apply them back to trunk.
To revert trunk:
(It wouldn't matter which order you performed these in, so you could revert trunk before creating the branch.)
Then you could switch to the new branch you created in the repo:
老实说，我将更改复制下来，恢复主干、分支，然后将更改提交到分支。 主要原因是以后易于合并（如果您稍后从主干合并到分支点的分支，则合并将包含初始更改的恢复）。
这可能不是“正确”的方式，因为您在合并时总是可以跳过修订，但以后对我来说通常不会那么头痛。 免责声明：我不是 svn 专家，所以这对我来说可能更容易，因为我做错了 - 但我确实经常使用 svn。
To be honest, I copy my changes off, revert trunk, branch, then commit my changes to the branch. The main reason being ease of merge later (if you later merge from the trunk to the branch at branch point, the merge will contain a revert of your initial changes).
This may not be the "correct" way, as you can always skip revisions when merging, but it is normally much less of a headache for me later on. Disclaimer: I'm no svn guru, so it may be easier for me because I'm doing it wrong - but I do use svn quite a lot.
遵循菲利普的方法并没有什么问题，只是它在修订历史中留下了一些“痕迹”。 如果您想为了整洁而删除它们，并且修订位于 HEAD，您可以按照 这些说明。
更新： 菲利普的方法比问题中建议的方法更好，原因如下。 我和菲利普的方法类似，除了我建议从修订历史记录中删除修订，而不是恢复主干。 （正如我所说，只有当您要删除的所有修订都位于存储库的头部时才能完成此操作。）
There's nothing wrong with following Philip's method, other than it leaves some "cruft" in the revision history. If you wanted to removed them for tidiness sake, and the revisions are at HEAD you could remove them from the repository by following these instructions.
Update: Philip's method is better than the one suggested in the question for the reasons he stated. Mine and Philip's methods would be similar, except that insead of reverting the trunk I propose removing the revisions from the revision history. (as I said, this can only be done if all the revisions you want to remove are at the HEAD of the repository.)
我这里没有可用的 svn，但这就是我尝试执行此操作的方法：
确定历史上您开始提交不良内容的点（例如，当您处于“130”时修订版“100”）
这应该绕过不良内容不添加反向合并的历史记录（实际上，您绕过了 100 到 130 之间的主干历史记录，但您在分支中保留了该历史记录的链接，并且在强制 rev 的同时访问主干仍然会产生正确的历史记录）
那么
这应该可以工作，如果您想从主干中完全删除更改。 如果你想保留一些小的，你可以从分支到主干再次挑选它们（如果你使用 svn 1.5，它将跟踪合并点并避免虚假冲突）
I don't have svn available right here but this is how I would try to do it :
Determine the point in history where you started committing bad stuff (say revision "100" while you are at "130")
This should bypass the bad history without adding a reverse merge (actually you are bypassing the history of the trunk between 100 and 130 but you kept a link to that history in the branch and accessing trunk while forcing the rev will still yield the correct history)
Then
this should work if you want to completely remove the changes from trunk. If there are small ones you want to keep you can cherry pick them again from branch to trunk (if you use svn 1.5 it will track merge points and avoid spurious conflicts)