Daniel:
I think that simply enabling M<N (where it is now an error) will create the
situation where the user makes a mistake, gets something they don't expect
and tries to interpret it based on their desire - leading to confusion. I
believe M<N should still be an error. A new option (--reverse ?) should be
required to make it clear that the user wants the reverse blame walk.
Thank you.
Doug
On Thu, Jun 13, 2013 at 4:35 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Definition: "kidney blame" == "blame -r N:M" with M<N. Currently it is
> an error (raised by svn_client_blame5()).
>
> By and large, it should do exactly what 'blame -r M:N' does: walk the
> revisions from "before-the-colon revision" to "after-the-colon revision"
> and then print the contents of the "after the colon" revision, with each
> line annotated by the revnum of the "rightmost" (that is: nearest to the
> revnum on the right of the colon) revision within the range that added
> that line. In other words, if
> (iota_at_4, kappa_at_1), (iota_at_3, kappa_at_2), (iota_at_2, kappa_at_3), (iota_at_1, kappa_at_4)
> are pairs of byte-for-byte-identical files, then 'blame -r 1:4 kappa'
> and 'blame -r 4:1 iota' will output the same thing.
>
> Currently, the non-kidney blame checks one revision before the start ---
> that is, 'blame -r M:N' actually calls svn_ra_get_file_revs2(start=M-1,
> end=N). The purpose of this is to differentiate "lines added in rN"
> from "lines present since before rN". That makes 'blame -r M:N'
> correspond to 'diff -r M-1:N' or 'diff -c M:N', in that it also shows
> changes made _by_ rM, not only _since_ rM.
>
> That behaviour cannot easily replicated for the -r N:M case since it's
> not possible to cheaply find the "next interesting revision" after rN,
> but in any case I think it shouldn't be: 'blame -r M:N' should not have
> automagically decremented M --- instead, if the user had wanted to see
> what lines were added in rM, as opposed to before it, the user should
> have specified M-1 as the start revision. That way, 'blame -r M:N'
> would be consistent with 'diff -r M:N'.
>
> So I suggest that blame -r N:M not try to find the "next change after
> rN" (that's the analogous thing to what "decrement M" is in the '-r M:N'
> case). That means -r M:N and -r N:M are assymetrical, and I propose we
> fix that by making -r M:N not decrement M --- which we can probably only
> do in 2.0.
>
> ---
>
> Another issue: what should 'blame -r 3:3' do? Currently it is allowed,
> and prints '-' for lines added before r3 and '3' for lines added in r3.
> I am not sure whether that is intentional / by design, or just an
> accident of the fact that whoever added the 'end_rev < start_rev' check
> should have used the broader condition 'end_rev <= start_rev' instead.
> (See r7438 <-> http://svn.apache.org/r847512).
>
> It seems to me it should ideally print '3' for every line, and the user
> should pass '-r 2:3' if he wants to distinguish "added in r3" from
> "added before r3". It would be easy to preserve the current behaviour,
> though, of printing '-' rather than '2' (where '2' here is the youngest
> change to that line, for lines added before r3).
>
> ---
>
> Cheers,
>
> Daniel
>
--
Douglas B. Robinson | *Senior Product Manager*
WANdisco // *Non-Stop Data*
t. 925-396-1125
e. doug.robinson_at_wandisco.com
--
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.
Received on 2013-06-13 18:11:26 CEST