Version Control with Subversion - Common Use-Cases - Undoing Changes
Another common use for
roll back a change that has already been committed. Suppose
you're working away happily on a working copy of
/calc/trunk, and you discover that the
change made way back in revision 303, which changed
integer.c, is completely wrong. It never
should have been committed. You can use
to “undo” the change in your
working copy, and then commit the local modification to the
repository. All you need to do is to specify a
$ svn merge -r 303:302 https://svn.example.com/repos/calc/trunk
$ svn status
$ svn diff
# verify that the change is removed
$ svn commit -m "Undoing change committed in r303."
Transmitting file data .
Committed revision 350.
One way to think about a repository revision is as a
specific group of changes (some version control systems call
these changesets). By using the
-r switch, you can ask
to apply a changeset, or whole range of
changesets, to your working copy. In our case of undoing a
change, we're asking
changeset #303 to our working copy
Keep in mind that rolling back a change like this is just
like any other
operation, so you
to confirm that your work is in the state you
want it to be in, and then use
to send the final version to the repository. After
committing, this particular changeset is no longer reflected
Again, you may be thinking: well, that really didn't undo
the commit, did it? The change still exists in revision 303.
If somebody checks out a version of the
calc project between revisions 303 and
349, they'll still see the bad change, right?
Yes, that's true. When we talk about
“removing” a change, we're really talking about
removing it from
HEAD. The original change
still exists in the repository's history. For most
situations, this is good enough. Most people are only
interested in tracking the
HEAD of a
project anyway. There are special cases, however, where you
really might want to destroy all evidence of the commit.
(Perhaps somebody accidentally committed a confidential
document.) This isn't so easy, it turns out, because
Subversion was deliberately designed to never lose
information. Revisions are immutable trees which build upon
one another. Removing a revision from history would cause a
domino effect, creating chaos in all subsequent revisions and
possibly invalidating all working copies.
[an error occurred while processing this directive]