7

I want to revert a bad commit from command-line svn. The usual advice is to reverse merge the commit into your working copy and then commit the changes. In my case, the bad commit was a mis-typed svn import which trashed a portion of my repository I don't have checked out anywhere else. I could check out the affected directories and then follow the usual advice, but it would be more elegant if I could reverse-merge entirely using URLs, without a working copy. Is this possible?

Isaac Sutherland
  • 3,082
  • 4
  • 28
  • 37
  • Do you have access to the physical SVN repo? If so, the neatest thing to do would be to just cut the faulty commit from the history using `svnadmin dump`/`restore`. – krlmlr Jul 15 '12 at 01:16
  • Well, it's a HUGE repository, so dumping will take a long time unless I can dump/load just the last few revisions somehow? – Isaac Sutherland Jul 15 '12 at 01:56
  • Just how huge is huge? You can always pipe the `dump` output into `load`, then it's not even materialized. 1 GB/min or more should be feasible. See http://stackoverflow.com/questions/5566327/delete-all-traces-of-a-svn-commit for an explanation. – krlmlr Jul 15 '12 at 02:03
  • Upon reflection, my repo isn't nearly that big -- only 362M total. In my case, it was enough to do a sparse checkout (see http://stackoverflow.com/questions/50945/can-you-do-a-partial-checkout-with-subversion) with `--depth=immediates`, followed by appropriate deletes and a commit. I could accept an answer that shows how to use `svnadmin dump` and `load` to trim off the last commit in a repository, though ... – Isaac Sutherland Jul 15 '12 at 02:26
  • `svnadmin dump` has an `-r` switch that comes in handy here. Sorry I can't find the time to write a full answer. – krlmlr Jul 15 '12 at 02:33

1 Answers1

2

No, you can't simply merge via the URL because that would mean merging without even seeing the resulting merge -- a very bad practice.

There is a situation where this wouldn't be bad:

  • Someone did a terrible and massive change in revision 455, the current version. You could easily restore the repository to version 454 without worrying too much. No real need to see what the end result will be.

However, imagine this:

  • Someone did a terrible and massive change in revision 455. The current revision is now 460. There are now five new changes in Subversion. You can back out change set 455 like you did in the previous example, but you wouldn't get revision 454. Instead, you get revision 454 with the changes made in revisions 456 to 460. Some of those changes may be independent of the mess revision 455 made. Some of those changes may be due to changes made in revision 455.

I understand that there is now a big mess to clean up, but the reason you have that mess is because someone committed changes via the svn import command without first having to verify them before committing them. It's the reason I discourage use of the svn merge command.

David W.
  • 105,218
  • 39
  • 216
  • 337