Can I update an old revision in subversion and propogate changes to all newer revisions?

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 al开发者_运维百科l the way to the head revision. Is this possible?

---

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.

---

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?

---

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 a svnadmin 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.

---

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.