[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Kidney blame's behaviour and edge cases

From: Doug Robinson <doug.robinson_at_wandisco.com>
Date: Thu, 13 Jun 2013 12:10:49 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.