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_at_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_at_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_at_4
in HEAD):
$ svn log -rHEAD:1 ^/trunk/beta_at_4
svn: E160013: File not found: revision 5, path '/trunk/beta'
$ svn log -r1:HEAD ^/trunk/beta_at_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_at_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_at_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.
Received on 2011-03-07 14:58:58 CET