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@123454321
svn: 'myFolder/myFile' is not under version control

$ svn log myFolder/myFile@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@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@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@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

Reply via email to