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: Kidney blame's behaviour and edge cases
> On Fri, Jun 14, 2013 at 1:33 PM, Daniel Shahaf <danielsh_at_elego.de> 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 <danielsh_at_elego.de> wrote:
> >> > Doug Robinson wrote on Thu, Jun 13, 2013 at 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.
> >> >
> >> > 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 'blame -r 5:4' and
> >> > 'blame -r 4:5' do different things is the correct course of action.
> >> >
> >>
> >> Okay, I don't feel strongly about this. My only "argument" was that
> >> people are not used to thinking about the order of rev args when using
> >> blame. But that doesn't mean they can't get used to it ...
> >
> > Implemented in r1493027. No API changes are involved --- this simply
> > makes 'blame -r 5:4' do something instead of raising an error
> > immediately --- so I wonder if we should backport it.
> >
> > I'll go ahead and put it in STATUS towards 1.8.1, if people prefer a
> > backport not to happen they can go ahead and cast -0 votes and continue
> > discussion here.
>
> There are still two problems with the implementation you committed in r1493027:
>
> With 'svn blame M:N' where M>N
>
> 1) It's using the N as peg revision, while it should use M (but you're
> already working on that).
>
Should be fixed by r1493106. I'd welcome further review of that, I
am unsure that the "open ra session to the other svn_opt_revision_t"
part is idiomatic.
> 2) If N is before the item existed, I get:
> svn: E195012: Unable to find repository location for
> 'svn://localhost/path/to/file.txt' in revision 1
>
> It would be nice if you could just blame up to the oldest revision
> close to 'end' where the item still existed.
Yeah, it would be nice if 'svn blame -r HEAD:1' just worked even for
files added later. I can look into that, but not today :) It would
be helpful if someone could point me to another place in the codebase
that solves the same problem.
Cheers,
Daniel
Received on 2013-06-14 17:11:55 CEST