Once in a while, someone commits a revision that has to be rolled back later for some reason. Some teams do that as a matter of policy when people check in broken code that doesn’t compile or isn’t able to run all test cases successfully. Since Subversion (and similar revision control systems) are designed to never lose changes, this isn’t easily possible.
If a commit really has to disappear without traces for some reason, the only way is to import your repository into a new one leaving out the offending commit. That’s a rather drastic measure causing all kinds of problems with existing working copies, so use it with great care.
The approach used more often is to commit a new revision that takes back earlier changes. This is like undoing all changes manually and committing them in the usual way. The offending changes are still in the history, but don’t do harm anymore.
This command rolls back changes made in revision N, using a reverse merge:
svn merge -c -N .
Note the minus character in front of N. This is the same as the following command (which also works with older subversion clients):
svn merge -r N:N-1 .
Rolling back multiple changes (let’s say revisions LOW to HIGH, both inclusive) works the same way:
svn merge -r HIGH:LOW-1 .
Afterwards examine the changes made to the working copy and commit them.
To understand what’s happening here requires some background on what the merge command does conceptually: It records which changes have to be made to revision N to turn it into revision N+1 (called a delta) and applies it to the working copy. That’s not what we want in our scenario, so we reverse the usual order of revisions on the command line. Effectively, we tell the merge command to create a delta the other way round. The result is a "rewinding" of the code base.
