77

These instructions are a little intimidating and confusing: http://svnbook.red-bean.com/en/1.0/ch04s04.html#svn-ch-4-sect-4.3 . And also they don't seem to mention that it's much simpler if you haven't yet checked in after doing the "svn rm" [1].

So I thought this would be a good place to record a simpler answer for those googling for this.

[1] To an svn newbie, it might appear that "svn rm" immediately destroys the file. I recall doing svn rm thinking that would just remove it from source control and freaking out when the file itself actually disappeared. So a sub-question is, what's the right way to remove a file from version control without actually removing your local copy?

dreeves
  • 26,430
  • 45
  • 154
  • 229

6 Answers6

93

If you just did

svn rm foo.txt

then you can undo that with simply

svn revert foo.txt

If you already checked in after doing the "svn rm" then you can look at the log (svn log), find the last revision where the file existed, and grab it from that version.

One way to do that is to merge in the old revision that has the file. Assuming the current revision is 123 and the last version with that file is 120, then do this:

svn merge -r123:120

Maybe first do a dry run to make sure it won't do anything you don't want:

svn --dry-run merge -r123:120

For the sub-question, how to remove a file from svn without removing the local copy:

svn rm foo.txt --keep-local

Or, of course, you could just copy to a temp file before svn rm'ing and then copy back:

cp foo.txt foo.txt-tmp
svn rm foo.txt
(svn ci -m "just removed foo.txt from the repository")
cp foo.txt-tmp foo.txt
dreeves
  • 26,430
  • 45
  • 154
  • 229
  • 1
    The problem with merge is that it looses the previous history of the file. svn cp as detailed in Stefan's answer is probably better, as well as easier to understand. – Avi Jun 02 '10 at 21:48
  • I found if change the version order, it is only add the removed file to current working copy, without others change of none removed file, e.g. `svn merge -r120:123 svn_url .` – zhuguowei Sep 12 '16 at 03:13
  • `svn revert` did not work recursively and I had to do `svn stat | egrep ^D | cut -c8- | xargs svn revert` – Axel Bregnsbo Nov 29 '16 at 10:15
  • My problem with the "reverse merge" is that it creates a Tree Conflict. – UncaAlby Jan 10 '18 at 21:35
44

for whatever reason, the -r arg wasn't working for me (svn version 1.6.9). I tried before and after the src, but kept getting a message that the file was not found in the current revision (duh). Same with --revision. Using the @ style syntax worked though:

svn cp url/to/removed/foo.txt@4 foo.txt
Michael Rush
  • 3,950
  • 3
  • 27
  • 23
  • Never know what's the most simple way to determine last working version but this statement is gold. – Bernhard Döbler Jul 19 '17 at 13:12
  • what is the @ style syntax? – Ferdinando Randisi May 18 '18 at 15:25
  • Typically you'd `-r` for specifying a revision number (see [Revision Specifiers](http://svnbook.red-bean.com/en/1.8/svn.tour.revs.specifiers.html)). The `@` notation is for peg revision (see [Peg and Operative Revisions](http://svnbook.red-bean.com/en/1.8/svn.advanced.pegrevs.html)) – Michael Rush May 21 '18 at 21:22
  • 1
    If you don't want to worry yourself with finding the *actual URL* to your repo, you can use `^/path/from/repo/root` instead. For example, in my case, I used `^/trunk/path/to/my/file.js` to restore a file that was originally located at `path/to/my/file.js` in my working copy (which is `^/trunk`). – Eric Seastrand Jul 16 '18 at 20:27
  • This answer provides a lot of clarity to a concept I've been very confused about. I, too, was unable to "undelete" a file with -r with an error message claiming it's not in the current revision. After reading the link above about peg revisions, I take that to mean subversion wants me to specify a peg revision wth the at sign where that file DID exist, so it knows *which* (potential) copy of oldfile.c I'm asking for. – SirNickity Apr 21 '20 at 19:33
33

To remove a file but keep it in the working copy, use

svn rm foo.txt --keep-local

To get a file back after you've committed the remove, you can use either the merge command, or the copy command - both will preserve the file history. Since the merge way is already described elsewhere, here's the copy way:

svn rm foo.txt
svn ci foo.txt -m "removed file"
(now at r5 as an example)
svn cp url/to/removed/foo.txt -r4 foo.txt
svn ci foo.txt -m "got file back"
dreeves
  • 26,430
  • 45
  • 154
  • 229
Stefan
  • 43,293
  • 10
  • 75
  • 117
  • 7
    For me to work, the copy command must be a bit different : svn cp url/to/removed/foo.txt@4 -r4 foo.txt ---- without the @4 I get a "path not found" error – Barth Oct 05 '12 at 06:59
  • 1
    Yes, for me I found "url/to/removed" by running `svn info` in the directory and looking at the "URL" field. Then I also had to do the "@4" trick, and the "-r4" wasn't necessary. Interestingly, the file log history is restored, with the exception of the delete entry! – Heath Raftery Sep 24 '20 at 05:08
10

For TortoiseSVN users, this is very easily accomplished via the Repo Browser. Within the Repo Browser switch to the revision before the file was deleted (you can change the version using the "Revision:" button at the top right):

enter image description here

You should then be able to see the deleted file in its original location in the Repo Browser. Right-click on it and choose "Copy to working copy...":

enter image description here

The file will then be restored to your working copy ready to commit (as though svn added) and with its log history intact.

atkins
  • 1,963
  • 14
  • 27
4

To revert a deleted file in SVN. Find the revision number just before delete (say 341). Then revert that file alone to that revision number.

svn up -r341 [path_to_deletedFile]
Rejeev Divakaran
  • 4,384
  • 7
  • 36
  • 36
  • 3
    This gets another local copy, but the file remains "deleted" in the repository. Your next "svn up" will see it disappear. – UncaAlby Jan 10 '18 at 21:37
1

i used the copy menu item from the previous revision using tortoise, worked for me and kept the history.

WendyG
  • 570
  • 5
  • 29