How to Roll Back Changes using Subversion

A question I’ve often gotten is “How do I roll back some changes I made in Subversion?” I’m the company expert in Subversion here at mediaRAIN (another one of my hats) so I thought I’d answer the question one more time.

Subversion is great as it allows you to track every change you’ve made and go back to a previous version if needed. Sometimes you only need to go back to an earlier revision temporarily (for example to tag the project at that point). But other times you (or that lousy co-worker who left on vacation yesterday!) have introduced bugs or committed something you shouldn’t have. Now you need to roll back the broken revision(s). Looking at TortoiseSVN’s menu or going through the list of command-line options you’ll see … gasp! … subversion forgot a roll-back feature! How could they do that?! Isn’t that one of the main reasons for using a versioning system like Subversion?

Never fear, Subversion can roll back changes made, it’s just not labeled “Roll Back” and it doesn’t quite undo those changes. See, it is Subversion’s job to track every revision of a document whether good or bad. What if you rolled back the lousy co-worker’s changes and after he gets back from holiday he shoots you to death with his flying-ninja gun because you destroyed all that code he worked on for days? Not good, Subversion needs to remember even the bad times.

So if Subversion won’t go back, it must go forward, and what you really need is the merge feature. Merge let’s you take a collective group of changes between two places (two separate files or two separate revisions, or both) and merge them into your working copy. Why doesn’t it just merge it into the head revision? Well, you’ve got to TEST it first of course! Merge is also used to get changes from a branch to the trunk and visa-versa, so we need to use it the right way for roll-backs.

Because Merge will “apply the differences between two sources to a working copy path.” (command line help `svn help merge`) it takes three parameters: the first source, the second source, and the working copy path. Since you are rolling back changes the first source and second source will be the same path but different revisions. Make sure to use the HEAD revision (or later revision) first and the starting of the bad-news revision second since you are rolling BACK and not forward. Then you’ll set the working copy path (if you’re using TortoiseSVN that will just be the folder you right-clicked on) to the corresponding folder in your working copy.

Command-line Example:

merge svn://domain.com/repo/trunk/folder/changedFile.txt@HEAD svn://domain.com/repo/trunk/folder/changedFile.txt@215 ./folder/changedFile.txt

When using TortoiseSVN you can hit that “Show Log” button to find the revision easily. Command-line users will have to find it first, remember it (yeah, painful ;), and then use it.

You’re not done yet. Now you’ve removed those changes made from your working copy you still need to test your code and the commit the files back to the repository. This will create a new revision that is now fixed, but leaves the broken one in the repo still in case you ever want to “roll back your roll back.”