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])
- svn diff -rX:Y > a.patch
- patch -p0 < a.patch
- svn commit
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.
You can avoid using diff and patch, by using merge:
ReplyDeletesvn merge -r X:Y SVNURL
Version Control with Subversion: Undoing Changes
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.
ReplyDeleteBesides shorting the two lines into one, svn merge will also handle operations involving binary files or metadata changes.
ReplyDeleteDefinitely go with svn merge.
ReplyDeleteIf 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)
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.
ReplyDeleteAs Robert notes, you can do:
ReplyDeletesvn 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.