On Mon, 07 Mar 2011, Stefan Sperling wrote:
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):
I believe that users expect
svn log -rREV1:REV2 path@PEG
to mean "report everything that happened to path@REV between
revision REV1 and REV2, inclusive", with both creation and
deletion being events for potential inclusion in the report. It's
unfriendly for "path@PEG does not exist in revision REV1" or
"path@PEG does not exist in revision REV2" to be fatal errors that
prevent the display of information for revisions where path@PEG
does exist.
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 am not the original poster, but I would ask for this to be
changed so that it uses the revision in which path@PEG was deleted
as an upper limit, and the revision in which path@PEG was created
as a lower limit, no matter what -r says.
I'd also like deletion events to appear explicitly in the log, but
that's a separate issue. If ^/dir/subdir/file exists in revision
5, but ^/dir is deleted in revision 6, then I'd like "svn log -v
-q -r6 ^/dir/subdir/file@5" to print
r6 | author | timestamp
Changed paths:
D /dir
instead of
svn: File not found: revision 6, path '/dir/subdir/file'
--apb (Alan Barrett)
