tags:

views:

686

answers:

3

Hi all,

I managed to shoot myself in the foot this morning by doing the following:

  1. Started working on a change to my project
  2. Made a bunch of edits to a bunch of files
  3. Realized that my approach was all wrong, and that I needed to start over
  4. cd'd to the top level of my project and did a "svn --recursive revert ." to restore my local sandbox to its pre-changes state.
  5. Howled in horror as I realized that there had been a number of other changes outstanding in my local sandbox, and I had just obliterated all of them. (the svn server had been down last Friday so I hadn't been able to check them in, and I had forgot about them over the weekend)

Fortunately in this case I had done an "svn diff > temp.txt" before leaving work on Friday, and the temp.txt file was still on my hard drive, so I was able to feed that file into "patch" and recover my lost changes.

But for my future reference (i.e. the next time I make the same dumb mistake)... is there any way to tell svn to undo an "svn revert"? Does svn keep a backup of the local/not-checked-in diffs anywhere?

+10  A: 

No, absolutely NO.

If you say to Subversion it should revert a file, all changes are gone by the wind.

Only your memory can get them back.

Exception: New files you had added, will only lose their status "added", but the file will remain in this directory, only status is unknown("?")

Peter Parker
Addendum to the above: Version control only helps you if you actually commit the files. If you are in a position that killing your working copy will kill hours of work, then you aren't committing frequently enough.
msemack
Agreed... in this case the svn server was down, and that's why I had un-committed changes still pending. :^(
Jeremy Friesner
If this happened, you can just file-copy your whole working copy to continue on a different task. In this way your task can still be committed into single commits
Peter Parker
+2  A: 

Not really Subversion specific, but if you're working with Eclipse, you can try your luck in the local history.

Now, something a little bit more Subversion specific: if you don't want to make a branch for every change you do, you can keep a couple of trunk checked out locally (trunk-modif-1, trunk-modif-2...). Each "modification" is done on a separate tree and you only need to keep a list of which check out correspond to which modification.

Or you could use Git locally but I never tried it.

Vladimir
+2  A: 

There is a solution... go to your recycle bin you'll find there the latest version of the deleted file. Tortoise "throwing" to the recycle bin every file that it revert.

shto
Incidentally, this is also why TortoiseSVN seems so slow when doing reverts. Moving a file to the recycle bin is a very slow operation when the recycle bin is full. You can disable this feature in the "General - dialogs 1" TortoiseSVN settings.
Wim Coenen
Thanks man, you saved me! I accidentally did Revert and almost lost 2 weeks of work. Fortunately, I found it in the recycle bin.
Arie Livshin