Friday, February 08, 2008

Subversion: Rolling back revisions

Earlier this week someone mistakenly checked in some experimental code and wanted to back that code out. If you've never needed to do this, you might think that Subversion gives you a command to make this happen easily, it doesn't. In fact, I've found that to be a fairly common misconception.

There may be easier ways, but the following steps are the ones I take to roll back a specific revision.

Find the revision that you wish to back out. This can be done with various tools, but 'svn log --limit 10' will probably do the trick. Once you have the offending revision you are ready to get started. (Revision X in the example is the revision that needs to be rolled back and revision Y is the revision that came immediately before X [i.e. X-1])
  1. svn diff -rX:Y > a.patch
  2. patch -p0 < a.patch
  3. svn commit
note: while it's possible to give patch parameters and do this pretty much anywhere in the tree, I'd stick to doing this in the root folder of your project, for simplicity.

Again, there is probably an easier way to do this (which is part of my motivation for writing this entry), and obviously this solution depends on having 'patch' available.


  1. You can avoid using diff and patch, by using merge:

    svn merge -r X:Y SVNURL

    Version Control with Subversion: Undoing Changes

  2. The only reason that I have a copy of Eclipse (Aptana, actually) on my machine is because it makes this _so_ easy with the Subclipse plugin. It will generate all of the svn merge commands for you and do everything in the background to back something out.

  3. Besides shorting the two lines into one, svn merge will also handle operations involving binary files or metadata changes.

  4. Definitely go with svn merge.

    If you're using a relatively recent version of svn, and it's only one revision you want to rollback, you can do:

    svn merge -c -X

    (without the - in front of the X, it tries to merge X in, not out - great for rolling forward)

  5. This is one reason I prefer darcs. You can pull a patch out of the repository if you know no-one else is relying on it, and it's as if it never happened.

  6. As Robert notes, you can do:

    svn merge -c-X

    where X is the single revision the change happened. the -c is to specify a single revision, and leading the revision with a '-' indicates it should be reversed.

    Ash, that's just wrong! The whole point of revision control is that it should maintain a complete history of the changes to your code. The metadata associated with each change (the log message, for example) is invaluable in explaining *why* something was done, or why it was wrong. It's one of the major problems I have with most dvcs (git, darcs, etc) solutions; it becomes possible to lose revisions and revise history.


Note: Only a member of this blog may post a comment.