Revision number where a file is deleted is NOT visible in the file's history, but buried in the folder's history - Please document that in svnbook, and add a FAQ

A) Naive goal
-------------
A naive goal is to display the whole history of the 'myFolder/myFile' file, INCLUDING the number and message of the revision where the file has been deleted.

B) Naive commands fail
----------------------
Firstly, following 2 naive commands completely fail, because the file does NOT exist anymore in BASE and HEAD :

$ svn log myFolder/myFile
svn: 'myFolder/myFile' is not under version control

$ svn log $REPO/myFolder/myFile
svn: File not found: revision 123456789, path '/myFolder/myFile'

C) Discover an adequate peg revision
------------------------------------
So, in order to discover some revision number where 'myFile' existed (peg revision), the user has to use following command :

$ svn log -v myFolder
... Potentially very long output ...

But a simple 'grep' can NOT provide the desired revision number, so the user has to manually parse this (potentially very long) output in order to find the string '/myFolder/myFile' where action is not 'D', and then search upward the corresponding revision number.

At the end of this work, the user hopefully has found a peg revision, say 123454321, and must memorize it.

D) Even with peg revision, commands using local names also fail
---------------------------------------------------------------
Using the local name of the file inside the working copy completely fails.
This was already reported by 'Zing' at http://svn.haxx.se/users/archive-2009-02/0822.shtml
---> My personal opinion is that this is a real bug. <---

$ svn log myFolder/myFile_at_123454321
svn: 'myFolder/myFile' is not under version control

$ svn log myFolder/myFile_at_123454321 -r 123454321:0
svn: 'myFolder/myFile' is not under version control

E) With peg revision and URL, naive command fails
-------------------------------------------------
Even with peg revision and URL, following naive command fails, because the file does NOT exist anymore in HEAD :

$ svn log $REPO/myFolder/myFile_at_123454321 -r HEAD:0
svn: File not found: revision 123456789, path '/myFolder/myFile'

F) Peg revision, URL and restricted revision range partially succeed
--------------------------------------------------------------------
Following command using peg revision, URL and restricted revision range succeeds, but does NOT display the number and message of the revision where the file has been deleted :

$ svn log $REPO/myFolder/myFile_at_123454321 -r 123454321:0
... History only between the peg revision and the beginning ...

G) Naive goal requires complex processing
-----------------------------------------
In fact, Ben Collins-Sussman explains at http://svn.haxx.se/users/archive-2005-07/0377.shtml that deleting a file is NOT a change to the file, but a change to its parent.

Therefore, an 'svn log' of the file can NEVER display the number of the revision where the file has been deleted (I suppose that this is not a bug, but a feature).

The only known way to fulfill the naive goal of displaying the whole history of the deleted 'myFolder/myFile' file is to use following procedure :

1) Parse the output of 'svn log -v myFolder' to find the first occurrence of the string 'D /myFolder/myFile',

2) Search upward the corresponding revision number (this is the number of the revision where the file has been deleted, say 123455555)

3) Memorize this number,

4) In order to display the message corresponding to the file deletion, type the following command using this number :

   $ svn log $REPO/myFolder -r 123455555

5) In order to display the history of the file before the deletion, type the following command using this number minus one :

   $ svn log $REPO/myFolder/myFile_at_123455554 -r 123455554:0

H) User documentation and issue list
------------------------------------
- Please check if the above description is relevant and accurate,

- Please create a corresponding FAQ using section G above,

- Please document that clearly inside the Subversion book, in particular in following sections :
   . Chapter 2. Basic Usage / Examining History / Generating a List of Historical Changes
   . Chapter 4. Branching and Merging / Basic Merging / Resurrecting Deleted Items

- If the behavior described in section D above is a real bug, please enter it as defect in the subversion issue list.

Thank you in advance for your work.

Best regards. Etienne URBAH
Received on 2011-03-22 01:33:21 CET