我可以在 subversion 中更新旧版本并将更改传播到所有较新的版本吗？
我已经纠正了当前有效的旧版本代码中的错误。还有尚未经过测试的较新修订版。我希望能够将此修复提交到旧版本，并让更新一直进行到头版本。这可能吗？
I have corrected a bug in an old revision of code that is currently live. There are newer revisions that have not yet been tested. I would like to be able to commit this fix to the old revision and have the updates carry through all the way to the head revision. Is this possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想你问的是“我可以让 SVN 更新我的所有代码，从修订版 X 到 Head，由我自动检查修订版 X 的修复” - 答案不是我所知道的。
正常用法是使用修复程序更新您的发布分支，然后将错误修复移动（合并/提交/等）到主干/开发中分支。这是为了确保 rev X 正确更新、测试等，然后你的主干/开发中分支也是如此。
What I think you're asking is "Can I have SVN update all my code, from revision X, through the Head, automatically by me checking in a fix to revision X" - The answer would be not that I know of.
Normal usage would be to update your Release branch with the fix, then move (merge/commit/etc.) the bug fix to the trunk/in-development branch. This is to ensure that rev X is updated, tested, etc. correctly, and then that your trunk/in-development branch is as well.
您可以将其提交到旧版本，然后将该特定版本合并到 HEAD 中。
例如，Subversion：如何仅合并当分支中进行多次连续更改时，对主干进行特定修订？
You can commit it to the old revision and then merge that specific revision into HEAD.
E.g., Subversion: How to merge only specific revisions into trunk when multiple consecutive changes are made in a branch?
你无法改变历史。如果您在旧版本的 Subversion 中犯了错误，则无法修改已提交的修订来修复此错误。您只需执行一次新的提交即可。
现在，当我说你无法改变历史时，我的意思是没有简单的方法。您可以执行
svnadmin dump，弄乱结果，然后有选择地执行svnadmin load。我不是 100% 确切地知道该怎么做。我使用转储和加载技术来删除其中包含不应该出现在我们的存储库中的专有信息的修订版。但是，我从来没有为了纠正一个老错误而搞乱历史。
而且，你可能真的不想这样做。想象一下，如果 bug 出现在修订版 #23 中，并且您已修复它。使用您的代码修订版 #26 的人正在尝试找出问题所在，但无法在源代码中找到问题。最后，最好说实话：我们犯了一个错误，我们需要修复它。
我可以想象你的主干修订版 #24 中有一个错误，客户想要修订版 #28，而你的主干现在是修订版 #50。如果您修复了修订版 #24 中的错误，您可以向客户提供修订版 #28。在这种情况下，您应该为版本 #28 创建一个分支，并修复该分支中的错误。
您可以执行以下操作：修改提交语句以包含有关错误的注释，以便其他人收到警告。
You can't change history. If you made a mistake in an old version of Subversion, you can't modify already committed revisions to fix this error. You simply have to do a new commit.
Now, when I say you can't change history, I meant there's no easy way. You can do a
svnadmin dump, muck up the results, and then selectively do asvnadmin load.I'm not 100% sure exactly how to go about it. I have used the dump and load technique to remove a revision that had proprietary information in it that shouldn't have been in our repository. But, I've never muck up the history to correct an old mistake.
And, you probably really don't want to. Imagine if the bug is in revision #23, and you fixed it. Someone with revision #26 of your code is trying to figure out what's wrong, but can't find the problem in the source. In the end, it's best to be honest: We made a booboo, and we need to fix it.
I can imagine where you have a bug in revision #24 of trunk, the customer wants revision #28, and your trunk is now on revision #50. If you fix the bug in revision #24, you can give the customer revision #28. In this case, you should create a branch for version #28, and fix the bug in that branch.
Here's something you can do: Modify the commit statement to include a note about the bug, so others are warned.
你为什么要这么做？为什么不直接做出改变并提交呢？
像 Subversion 这样的产品的全部意义在于，它会跟踪所做的所有更改，并允许您准确地查看任何时间点代码（或任何文本）的状态。如果您可以返回并更改早期的修订，那么就不再可能说出何时进行了哪些更改。
通过更改早期版本您会得到什么？我正在尝试找出你为什么想要这样做。如果您将 1 月 1 日的修订版 10 更改为 2 月 12 日的更改，这意味着什么？那么现在修订版 10 不再是以前的修订版 10 了？现在是 1 月 1 日提交还是 2 月 12 日提交？如果有人想知道我们在 1 月 2 日拉取版本进行部署时的代码是什么样的，SVN 会告诉他们什么？你想做的只会打破 SVN 的整个概念。
Why would you want to do that? Why not just make the change and commit?
The whole point of a product like Subversion is that it keeps track of all changes made, and allows you to see exactly what the state of the code (or whatever text) was at any point in time. If you could go back and change earlier revisions, then it would no longer be possible to say what change was made when.
What would you gain by changing an earlier revision? I'm trying to figure out why you would even want to do this. What would it mean to say that you change revision 10 dated January 1 with a change made on February 12? So now revision 10 isn't what revision 10 used to be any more? Is it now the January 1 commit or is it a February 12 commit? If someone wants to know what the code looked like when we pulled a version to deploy on January 2, what would SVN tell them? What you want to do would just break the whole concept of what SVN is all about.