On Mon, 07 Mar 2011, Stefan Sperling wrote:
> 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):
I believe that users expect
svn log -rREV1:REV2 path_at_PEG
to mean "report everything that happened to path_at_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_at_PEG does not exist in revision REV1" or
"path_at_PEG does not exist in revision REV2" to be fatal errors that
prevent the display of information for revisions where path_at_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_at_PEG was deleted
as an upper limit, and the revision in which path_at_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_at_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)
Received on 2011-03-08 09:17:01 CET