examining history of deleted file

If I delete a file in Subversion, how can I look at it's history and contents? If I try to do svn cat or svn log on a nonexistent file, it complains that the file doesn't exist.

Also, if I wanted to resurrect the file, should I just svn add it back?

(I asked specifically about Subversion, but I'd also like to hear about how Bazaar, Mercurial, and Git handle this case, too.)

From stackoverflow

• You would need to specify a revision.

  svn log -r <revision> <deleted file>
  

  Jeremy : This gives an error. Example: svn log -r 37428 http://svn.example.com/deletedfile.java svn: '/!svn/bc/98571/deletedfile.java' path not found

  Jack M. : Are you sure it existed at that revision? You have to specify a revision where the file actually existed.

• To get the log of a deleted file, use

  svn log -r lastrevisionthefileexisted
  

  If you want to resurrect the file and keep its version history, use

  svn copy url/of/file@lastrevisionthefileexisted -r lastrevisionthefileexisted path/to/workingcopy/file
  

  If you just want the file content but unversioned (e.g., for a quick inspection), use

  svn cat url/of/file@lastrevisionthefileexisted -r latrevisionthefileexisted > file
  

  In any case, DO NOT use 'svn up' to get a deleted file back!

  rmeador : You can also ressurrect the file by doing a reverse merge of the revision in which you deleted it. This is the procedure recommended in the SVN docs. As for using "svn up", it's not so much a matter of "don't do it" as it is "it will not do what you want it to do".

  Benjamin Peterson : How can I see the file's whole history, though?

  rmeador : I'd edit the answer if I could, but since I can't, the way to get the whole log is to use a revision range of the form 1:lastrevisionfileexisted (or perhaps it starts at zero... can't remember)

  Jeremy : The trick is: How do you find lastrevisionthefileexisted?

  Stefan : Simple: show the log for a parent folder with the '-v' switch: you'll get for every entry a list of changed paths. Find the one with a 'D' in front and the name of your deleted file. That's the revision where the file got deleted.

  Keith Palmer : This doesn't seem to work for deleted files. If I try this, I get this error message: svn cat [url]/trunk/include/syeka/poster_funk.incl.php -r 50 > out.txt svn: '/admintools/!svn/bc/131/trunk/include/syeka/poster_funk.incl.php' path not found See @Bert Huijben's response further down this thread for a working solution.

• First, find the revision number where the file got deleted:

  svn log -v > log.txt
  

  Then look in log.txt (not an SVN guru, so I don't know a better way) for a line with

  D <deleted file>
  

  and see which revision that was. Then, as in the other answers, resurrect the file using the previous revision.

  abatishchev : svn log -v | grep D "file.name"

  Chris S : +1 for being the first person to correctly answer the question. You can't look at the contents if you don't know the revision before it was deleted.

• It's nothing particularly special in git. If you know the name of the file, you can find out the change that removed it with log:

  git log -n 1 -- filename
  

  Then you can use that commit to get the file as it existed before the deletion.

  git checkout [last_revision]^ filename
  

  Example:

  dhcp-120:/tmp/slosh 587% ls -l slosh.tac
  ls: slosh.tac: No such file or directory
  dhcp-120:/tmp/slosh 588% git log -n 1 -- slosh.tac
  commit 8d4a1f1a94e4aa37c1cb9d329a140d08eec1b587
  Author: Dustin Sallings <dustin@spy.net>
  Date:   Mon Dec 15 11:25:00 2008 -0800
  
      Get rid of a .conf and replace it with .tac.
  dhcp-120:/tmp/slosh 589% git checkout 8d4a1f^ slosh.tac
  dhcp-120:/tmp/slosh 590% ll slosh.tac
  -rw-------  1 dustin  wheel  822 Dec 30 12:52 slosh.tac
  

  Note that this does not actually put the file back in revision control. It simply drops the file as it existed in its final state into the current location. You can then add it or just inspect it or whatever from that point.

• In addition to Dustin's answer, if you just want to examine the contents, and not check it out, in his example you can do:

  $ git show 8d4a1f^:slosh.tac
  

  the : separates a revision and a path in that revision, effectively asking for a specific path at a specific revision.

  Dustin : Ah, very true. I used to do that the really, really hard way. :)

• Ah, since I am learning to use Bazaar, it is something I tried. Without success, it appears you cannot log and annotate removed files currently... :-(

  Tried:

  > bzr log -r 3 Stuff/ErrorParser.hta
  bzr: ERROR: Path does not have any revision history: Stuff/ErrorParser.hta
  

  but curiously (and fortuntely) I can do:

  > bzr cat -r 3 Stuff/ErrorParser.hta
  

  and:

  > bzr diff -r 2..3 Stuff/ErrorParser.hta
  

  and as suggested in the bug above:

  > bzr log -v | grep -B 1 ErrorParser
  

  (adjust B parameter as needed).

• When you want to look at old files you really should know the difference between:

  svn cat http://server/svn/project/file -r 1234
  

  and

  svn cat http://server/svn/project/file@1234
  

  The first version looks at the path that is now available as http://server/svn/project/file and retrieves that file as it was in revision 1234. (So this syntax does not work after a file delete).

  The second syntax gets the file that was available as http://server/svn/project/file in revision 1234. So this syntax DOES work on deleted files.

  You can even combine these methods to retrieve a file that was available in revision 2345 as http://server/svn/project/file but with the contents as it had in 1234 with:

  svn cat http://server/svn/project/file@2345 -r 1234
  

  Keith Palmer : Gah, thanks! The current top response in this thread does not mention this, this is great!

• If I first delete a file and then add a modification of it back again I would like to see in the log the entry of the revision where it got deleted and the entry where it got added back.

  Why would I delete files and add them back ? Because this is how software can be updated: delete the old release and add back the new release.

  Apparently this is not easy or even possible in subversion. In perforce it is no problem. I remember but I am not completely sure that this is also possible in CVS and Clearcase.