On Tue, Oct 14, 2003 at 12:16:49AM +0100, Julian Foad wrote:
> "svn blame" is great. It's a really big step to nail the last remaining
> publically-obvious missing CVS feature. So don't interpret this as a
> complaint; its just a bit of development work. I already saw a mention of
I knew it was a strawman when I committed it. :-)
> "blame" not working well with revision specifiers, but I can't find that
> now.
You may be remembering that it didn't work without them until rev 7390.
>
> Proposal:
> [[[
> "svn blame -rX FILE"
> - Give the origin of each line of the file "FILE@X".
>
I was thinking that this should mean "Give the origin of every change
since FILE@X". Sort of like "svn diff -rX FILE", except with author
info. I guess you're thinking more along the lines of "svn cat -r X FILE".
Hmm.
> "svn blame -rX:Y FILE" (X >= Y)
> - Give the origin of each line of the file "FILE@X" that originated in or
> after revision Y, or an "unknown origin" indication if the line originated
> before revision Y.
I was thinking that this should be an error.
>
> "svn blame -rX:Y FILE" (X < Y)
> - Error.
I was thinking that this should be something like what you've outlined
for the previous case.
>
> "svn blame FILE"
> - Shorthand for "svn blame -rHEAD FILE".
>
Right.
> The "unknown origin" indication is "-" for the revision number and "-" for
> the author.
> ]]]
>
>
> Notes and explanations:
>
> This definition of "-rX" is the same as in "cvs annotate". I think the
> current "svn blame" interprets "-rX" as "annotate FILE@HEAD from rX to
> rHEAD" which is, in my opinion, confusing, partly because FILE@BASE could
> equally well be expected or desired, but mainly because of the expectation
> that (only) the lines that existed in FILE@X will be shown.
You've convinced me. Mostly. My expected use-case is something
like "what changes were made since the branch?". Of course, I could use
an explicit -r X:Y in order to accomplish that.
> The reasons for "-rX:Y" meaning "FILE@rX back to rY" are:
> - It fits with the "-rX" case: together they can be desribed as
> "-rX[:LIMIT]". Otherwise, while "-rX" describes FILE@X, "-rX:Y" would
> describe FILE@Y, which is harder to teach and to learn.
> - This is an inherently backward-looking operation, so having the larger
> number first is OK, unlike "diff" and "log" which can be thought of as
> going either way and therefore accept a reversible revision range.
Well, the alternative could be described as -r [START:]STOP, but
I do see your point. Also, that's how the code will need to work, once
it starts tracing copy history.
> The reason for (X < Y) being an error is that it would introduce a
> confusion about which version of the file is to be annotated: FILE@X or
> FILE@Y. It would be possible to write a forward-looking annotator which
> says who was the next person to change each line of this old file, and, for
> that, "-rX:Y" (X < Y) would be appropriate.
What a wonderful tool! "Who deleted the check for NULL?".
> This definition of "-rX:Y" includes changes made between revision (X-1) and
> (X). I am not sure whether it should. I would like it to be consistent
> with other commands, but there is already an inconsistency between "log"
> and "diff". This "inclusive" definition matches "log" and the
> implementation must remember to fetch the diff that created revision X from
> a previous revision as well as those between X and Y.
Good point. I don't know what the right thing to do here is, either.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 14 16:25:23 2003