Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Retract accidental checkin

Tags:

svn

You're using subversion and you accidentally checkin some code before it's ready. For example, I often: a) checkin some code, then b) edit a little, then c) hit up, enter to repeat the previous command which unfortunately was a checkin.

Is it possible to retract such an accidental checkin from the server with subversion?

like image 567
moinudin Avatar asked Apr 14 '09 14:04

moinudin


3 Answers

See the SVNBook, specifically the 'Undoing Changes' section, and reverse merging.

Another common use for svn merge is to 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 svn merge 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 reverse difference:

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk

To clarify, your initial change will still be in the repository. But you've now retracted it in a later revision. i.e. the repository has captured all your changes (which is really what you want! Unless you've checked in a plaintext password or similar!)

like image 132
Brian Agnew Avatar answered Oct 05 '22 13:10

Brian Agnew


NB: THIS PROBABLY WON'T WORK ON CURRENT VERSIONS OF SUBVERSION AND IS A BAD IDEA - but I've left it here for information

NB: Normally when you have checked in by mistake, you should just revert the commit - see the other answers to this question. However, if you want to know how to actually undo the effects of the commit and change the repository to be how it was before, there's some explanation below:

This isn't what you normally want, but if you really want to remove the actual committed version from the repository, then you can do a nasty rollback on the repository as follows (this assumes that $REV is set to the latest revision, which you are removing):

  • Backup your repository first as these changes may break it (and read the assumptions below)
  • Revert your local copy to the previous revision so it doesn't get confused (svn revert -r $((REV-1)))
  • In the repository, remove db/revs/$REV and db/revprops/$REV
  • In the repository, remove db/current and (for subversion 1.6 or greater) db/rep-cache.db, and run svnadmin recover .
  • (Possibly) adjust the permissions on db/rep-cache.db to prevent attempt to write a readonly database errors

This all assumes:

  • You're using a fsfs-based repository
  • Subversion release greater than 1.5.0 (otherwise you have to manually edit db/current and change the revision number rather than running svnadmin recover .)
  • No other subsequent revisions have been committed
  • You have write access to the filesystem of the repository
  • You aren't scared of somebody else trying to access it while you do the above

I've done it when a huge file was committed to a repository that I didn't want to stay in the history (and mirrors etc) forever; it's not in any way ideal or normal practice...

like image 40
David Fraser Avatar answered Oct 05 '22 13:10

David Fraser


WARNING: The accepted answer (by David Fraser) should work with an SVN 1.5 repository, but with SVN 1.6 you must also delete db/rep-cache.db before the next commit or you'll corrupt your repository and may not realize it until the next time you try a complete checkout. I've seen subsequent complete checkouts fail with a "Malformed representation header" error.

What is rep-cache.db, you may ask? The documentation on the FSFS layout says that you will lose "rep-sharing capabilities" if you delete this file; however, it will be recreated on your next commit. Representation sharing was added in 1.6.

like image 25
Pete Avatar answered Oct 05 '22 12:10

Pete