"S.Ramaswamy" <srsy70@gmail.com> writes:
> > 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.
Well, there have been no responses to my post, which was one week ago:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=102118
I think then that we should implement the behavior proposed in that
mail, that is, 'svn log -rN foo' should stop behaving as though -rN
were a peg revision, and start being consistent with other commands,
by treating "-rN" and "@n" in subtly different ways.
> > 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 ?
Oops -- my fault, thanks for the correction! Okay, then IMHO in this
respect the current behavior of 'svn log' is fine and does not need to
change. Which means it's also okay to check just the first target for
a peg rev.
Eagerly awaiting the next version of the patch (v2, I guess?),
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 7 22:21:04 2005