On Mon, Mar 07, 2011 at 01:29:29PM +0100, Avalon wrote: > For the svn log command the direction "-r N:1" works fine - even if the > resource does NOT exist in revision one. > So in this case the resource is NOT checked to exist in both start and end > revision. >
Ah, I think I see where your problem is. Note that -rN:1 is a very different revision range than N:HEAD. With N:1, you end up asking for the log of the file as of revision N. With HEAD:1 you're asking for the file in HEAD. This may need some explanation: svn log will first try to locate the path in a revision called the "peg revision". This is the HEAD revision by default. If it doesn't find the path there, an error is raised. svn help log says this about *peg* revisions: 2. log URL[@REV] [PATH...] 2. Print the log messages for the PATHs (default: '.') under URL. If specified, REV is the revision in which the URL is first looked up, and the default revision range is REV:1; otherwise, the URL is looked up in HEAD, and the default revision range is HEAD:1. For instance, say the file /trunk/beta was removed in r5, and we ask for its log in HEAD (which is r5). This doesn't work, because beta was deleted in r4: $ svn log ^/trunk/beta svn: E160013: File not found: revision 5, path '/trunk/beta' (The ^/ is a shorthand to the repository root.) We can ask for a different peg revision X by appending @X to the path: $ svn log ^/trunk/beta@4 ------------------------------------------------------------------------ r4 | stsp | 2011-03-07 13:59:10 +0100 (Mon, 07 Mar 2011) | 1 line m ------------------------------------------------------------------------ r1 | stsp | 2011-03-07 13:58:54 +0100 (Mon, 07 Mar 2011) | 1 line importing project tree ------------------------------------------------------------------------ The above is the full history for the file. This uses the range 4:1, because we didn't specify any range (i.e this is what REV:1 is supposed to mean in the help text). When we specify a -r option, we usually want to limit the amount of log messages printed by the above command. So -r acts like a filter on the above output. The problem is that the client blindly trusts the revision range specified by the user. It doesn't check whether the revision range being asked for makes sense for the given peg revision. By asking for beta@4 with a revision range of 1:HEAD, we're asking an invalid question because the revision range is not valid for this path. There is no log to show in HEAD, so it errors out (you can think of this as the filter trying to eliminate elements which don't exist, but what really happens is that a request is sent to the server to open beta@4 in HEAD): $ svn log -rHEAD:1 ^/trunk/beta@4 svn: E160013: File not found: revision 5, path '/trunk/beta' $ svn log -r1:HEAD ^/trunk/beta@4 svn: E160013: File not found: revision 5, path '/trunk/beta' If we omit the -r option, the default of -r1:4 (or -r 4:1) is used, which works: $ svn log -r1:4 ^/trunk/beta@4 ------------------------------------------------------------------------ r1 | stsp | 2011-03-07 13:58:54 +0100 (Mon, 07 Mar 2011) | 1 line importing project tree ------------------------------------------------------------------------ r4 | stsp | 2011-03-07 13:59:10 +0100 (Mon, 07 Mar 2011) | 1 line m ------------------------------------------------------------------------ $ svn log -r4:1 ^/trunk/beta@4 ------------------------------------------------------------------------ r4 | stsp | 2011-03-07 13:59:10 +0100 (Mon, 07 Mar 2011) | 1 line m ------------------------------------------------------------------------ r1 | stsp | 2011-03-07 13:58:54 +0100 (Mon, 07 Mar 2011) | 1 line importing project tree ------------------------------------------------------------------------ Does this make sense? I suppose you're asking for this to be changed so that it doesn't require the user to always specify a valid revision range for -r, by always using the peg revision as an upper limit no matter what -r says. I would expect that there have been past discussions about this. The archives should first be searched to determine whether or not there was a concious decision behind the current behaviour.