subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Two questions about svn log of a deleted file
Date Thu, 08 Nov 2012 15:25:19 GMT
On Thu, Nov 08, 2012 at 03:15:49PM +0100, Niemann, Hartmut wrote:
> Hello!
> 
> (This is TortoiseSVN's command line client
>    svn, version 1.7.7 (r1393599)
>    compiled Oct  8 2012, 18:39:05, 
>  belonging to 
>    TortoiseSVN 1.7.10, Build 23359 - 32 Bit , 2012/10/08 11:46:26
>  on Windows XP, if that makes a difference)
> 
> I deleted a file a.txt in revision 1186.
>  
> 	svn log a.txt 
> gives 
> 	svn: E160013: File not found: revision 1197, path '/...
> which is not surprising.
>  
> But what is the canonical way of getting the latest log of this file?
>  
> svn log a.txt@1100 gives me the history up to rev. 1100
> svn log a.txt@1185 gives me the history up to rev. 1185 (which ends at rev 1132, no newer
changes)
> svn log a.txt@1186 gives me a file not found error.
> 
> Question 1:
> How do I get the complete newer history for a.txt@1100?
> 
> >From the help text I thought 
> svn log a.txt@1100 -r HEAD:1 or something like that shoud do it, but
> as the file is not present in HEAD I get a file not found error for all
> -r parameters involving HEAD that I tried.

This is because the default peg revision is HEAD with such an
invocation. See http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
(I'm just mentioning this for completeness -- given what you're saying
above you seem to understand this already.)

> Question 2:
> Tortoise SVN has a log view where all files changed in a revision, 
> including this deleted one, are shown. (At the moment I do not need to know
> how this can be done with command line svn.)
> I can get a log for this file from there, but this log stops at revision 1132.
> 
> Is my observation correct that the log information for a file
> does not include it's deletion?

Yes, a deletion of a node is an operation on the node's parent because
of the way Subversion's repository is structured.
Recall that files and directories are both versioned explicitly, and
that the list of children is one versioned component of a directory.

> Is this a good idea? Or am I missing something?
> 
> How would one answer the question "when was file a.txt deleted, which 
> was present in revision 1100 and is missing now"?

The current answer isn't very satisfying.
It is to run 'svn log -v' on a parent directory which has not been deleted
yet and search the log output for the filename. In the extreme case this
means running svn log on the repository root and searching all revisions.

In my opinion, the best answer is currently using TortoiseSVN's log
search feature and search for the name of the deleted file, simply
because it is faster.

In Subversion 1.8, 'svn log' will have a roughly similar feature.
It will allow filtering log messages based on search patterns matching
log message attributes and contents, including the list of changed paths
if the -v option is given. So in Subversion 1.8 you'll be able to run
something like 'svn log -v --search "a.txt" ^/trunk' which will only show
log messages which contain "a.txt" somewhere. This is still suboptimal
because it doesn't directly answer the question of when a.txt was deleted.
But at least you'll have a shorter list of log message to plough through.
And maybe the list can be made shorter by using a more precise search pattern.

Mime
View raw message