Julian Foad wrote on Fri, Feb 20, 2015 at 20:15:29 +:
> I (Julian Foad) wrote:
> > issue #4565 "reverse blame, aka kidney blame"
> > [...] I want to see:
> >
> > * The first revision in which the line was changed (or deleted) after
> > r140.
>
> The following help text explains how I t
Bert fixed the code to work like this, in r1661208.
I committed help text, much like I pasted here, in r1661211.
- Julian
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>> issue #4565 "reverse blame, aka kidney blame"
>> [...] I want to see:
>>
>> * The first revision in which the line
I (Julian Foad) wrote:
> issue #4565 "reverse blame, aka kidney blame"
> [...] I want to see:
>
> * The first revision in which the line was changed (or deleted) after
> r140.
The following help text explains how I think it should behave:
[[[
blame (praise, annotate, ann): Show when each
I filed issue #4565 "reverse blame, aka kidney blame" to track this
enhancement, because I think it is useful to have an issue to coordinate any
change we make in a release.
It currently doesn't behave how I think it should. Try
svn blame -r160:140 ^/subversion/trunk/subversion/svn/sv
Paul burba added and shortly after reverted (as no longer used) code to
separate these steps. You can probably revive that code.
Bert From: Daniel Shahaf
Sent: 14/06/2013 17:49
To: Bert Huijben
Cc: Johan Corveleyn; Subversion Development
Subject: Re: Kidney blame's behaviour and edge cases
D
That function and the get revs function can only go from new to old.
That deleted rev is the only one for the other way From: Daniel Shahaf
Sent: 14/06/2013 17:41
To: Bert Huijben
Cc: Johan Corveleyn; Subversion Development
Subject: Re: Kidney blame's behaviour and edge cases
No typo, but
gt; > Bert From: Daniel Shahaf
> > Sent: 14/06/2013 17:11
> > To: Bert Huijben
> > Cc: Johan Corveleyn; Subversion Development
> > Subject: Re: Kidney blame's behaviour and edge cases
> > Bert Huijben wrote on Fri, Jun 14, 2013 at 08:06:25 -0700:
> > >
redone. I'm not sure how yet.
Bert Huijben wrote on Fri, Jun 14, 2013 at 08:24:58 -0700:
> Svn_ra_get_deleted_rev() ?
> (could have a typo)
>
> Bert From: Daniel Shahaf
> Sent: 14/06/2013 17:11
> To: Bert Huijben
> Cc: Johan Corveleyn; Subversion Development
> Subjec
Svn_ra_get_deleted_rev() ?
(could have a typo)
Bert From: Daniel Shahaf
Sent: 14/06/2013 17:11
To: Bert Huijben
Cc: Johan Corveleyn; Subversion Development
Subject: Re: Kidney blame's behaviour and edge cases
Bert Huijben wrote on Fri, Jun 14, 2013 at 08:06:25 -0700:
> I would guess 1 and
Bert Huijben wrote on Fri, Jun 14, 2013 at 08:06:25 -0700:
> I would guess 1 and twi are actually the same problem: no node found
> via peg revision.
>
> Bert From: Johan Corveleyn
> Sent: 14/06/2013 16:51
> To: Daniel Shahaf
> Cc: Subversion Development
> Subject: Re:
I would guess 1 and twi are actually the same problem: no node found
via peg revision.
Bert From: Johan Corveleyn
Sent: 14/06/2013 16:51
To: Daniel Shahaf
Cc: Subversion Development
Subject: Re: Kidney blame's behaviour and edge cases
On Fri, Jun 14, 2013 at 1:33 PM, Daniel Shahaf wrote:
&g
On Fri, Jun 14, 2013 at 1:33 PM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Fri, Jun 14, 2013 at 11:16:06 +0200:
>> On Fri, Jun 14, 2013 at 11:00 AM, Daniel Shahaf wrote:
>> > Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
>> >> Daniel:
>> >>
>> >> I think that simply enabling M
Johan Corveleyn wrote on Fri, Jun 14, 2013 at 11:16:06 +0200:
> On Fri, Jun 14, 2013 at 11:00 AM, Daniel Shahaf wrote:
> > Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
> >> Daniel:
> >>
> >> I think that simply enabling M >> situation where the user makes a mistake, gets something t
On Fri, Jun 14, 2013 at 11:36 AM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Fri, Jun 14, 2013 at 11:16:06 +0200:
>> On Fri, Jun 14, 2013 at 11:00 AM, Daniel Shahaf wrote:
>> > Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
>> >> Daniel:
>> >>
>> >> I think that simply enabling
Johan Corveleyn wrote on Fri, Jun 14, 2013 at 11:16:06 +0200:
> On Fri, Jun 14, 2013 at 11:00 AM, Daniel Shahaf wrote:
> > Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
> >> Daniel:
> >>
> >> I think that simply enabling M >> situation where the user makes a mistake, gets something t
Daniel Shahaf wrote on Fri, Jun 14, 2013 at 11:18:35 +0200:
> Prabhu wrote on Fri, Jun 14, 2013 at 14:33:57 +0530:
> > On 06/14/2013 02:30 PM, Daniel Shahaf wrote:
> > >Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
> > >>Daniel:
> > >>
> > >>I think that simply enabling M > >>the
> >
Prabhu wrote on Fri, Jun 14, 2013 at 14:33:57 +0530:
> On 06/14/2013 02:30 PM, Daniel Shahaf wrote:
> >Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
> >>Daniel:
> >>
> >>I think that simply enabling M >>situation where the user makes a mistake, gets something they don't expect
> >>and
On Fri, Jun 14, 2013 at 11:00 AM, Daniel Shahaf wrote:
> Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
>> Daniel:
>>
>> I think that simply enabling M> situation where the user makes a mistake, gets something they don't expect
>> and tries to interpret it based on their desire - lead
On 06/14/2013 02:30 PM, Daniel Shahaf wrote:
Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
Daniel:
I think that simply enabling M
Sorry, disagree.
diff -r 1:5 != diff -r 5:1
log -r 1:5 != log -r 5:1
merge -r 4:5 != merge -r 5:4
With all that in mind, I still think that making 'b
Doug Robinson wrote on Thu, Jun 13, 2013 at 12:10:49 -0400:
> Daniel:
>
> I think that simply enabling M 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 required to make it clear tha
Johan Corveleyn wrote:
>On Thu, Jun 13, 2013 at 6:10 PM, Doug Robinson
> wrote:
>> Daniel:
>>
>> I think that simply enabling Mcreate 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
On Thu, Jun 13, 2013 at 6:10 PM, Doug Robinson
wrote:
> Daniel:
>
> I think that simply enabling M 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 required to make it clear that the
Daniel:
I think that simply enabling M wrote:
> Definition: "kidney blame" == "blame -r N:M" with M 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
> -Original Message-
> From: Daniel Shahaf [mailto:danie...@elego.de]
> Sent: donderdag 13 juni 2013 10:36
> To: dev@subversion.apache.org
> Subject: Kidney blame's behaviour and edge cases
>
> Another issue: what should 'blame -r 3:3' do? C
Branko Čibej wrote on Thu, Jun 13, 2013 at 10:54:47 +0200:
> On 13.06.2013 10:35, Daniel Shahaf wrote:
> > 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 prese
On 13.06.2013 10:35, Daniel Shahaf wrote:
> 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
Definition: "kidney blame" == "blame -r N:M" with M 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,
tho
27 matches
Mail list logo
