>
> Ben and I just talked this over, and decided the old behavior
> (succeeding) was a "bug", and that the new failure is correct. The
> URL does not exist in HEAD, period. Therefore, this command
>
> $ svn log -rN url_not_present_in_head
>
> which has an implied peg rev
>
> $ svn log -rN url_not_present_in_head@HEAD
>
> should fail.
>
> However, this is an incompatible change that users are likely to
> notice. I think we should have a separate discussion about it. In
> order to do so, I will follow up to this mail with another mail, one
> with a more attention-getting subject, and refer people back to this
> thread.
>
I will wait for some time for responses to this and the other mail you sent,
before starting on the next version of the patch, since this is not an
insignificant UI change.
> What if other targets (besides the first) have peg revs on them?
>
> The old code was able to get away with checking just the first target
> because it checked the other targets for inconsistencies against the
> first target: if the first target was a URL, then everything had to be
> a URL, or else error. Or if it was a wc path, everything had to be a
> wc path.
>
> But here, you're parsing off a peg rev from the first target, while
> not addressing the question of what happens if there are peg revs on
> other targets.
Actually the way svn log works right now is,
(a) If it is a working copy path, only one wc path is allowed to
be specified.
(b) If the first arg is an url - the rest have to be relative paths.
Commands like 'svn cat' and 'svn blame' are different in that you are
allowed to have different wc paths or urls as arguments.
Should the current behaviour of 'svn log' be maintained or does
consistency demand that, svn log behave more like the other cmds ?
Thanks for the review.
Ramaswamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 4 17:19:20 2005