subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julian.f...@wandisco.com>
Subject Re: svn commit: r1131442 - /subversion/trunk/tools/client-side/svnmucc/svnmucc.c
Date Mon, 06 Jun 2011 11:09:50 GMT
On Mon, 2011-06-06 at 11:59 +0200, Stefan Sperling wrote:
> On Mon, Jun 06, 2011 at 10:17:01AM +0100, Julian Foad wrote:
> > FWIW the original reasoning is in Karl's comment in parse_one_rev():
> > 
> >   /* Allow any number of 'r's to prefix a revision number, because
> >      that way if a script pastes svn output into another svn command
> >      (like "svn log -r${REV_COPIED_FROM_OUTPUT}"), it'll Just Work,
> >      even when compounded.
> > 
> > I guess that means "even if one script, when given 'r123' as input, were
> > to print 'rr123' as output, then we could still pass in that output as
> > '-r rr123' and it would still work".
> > 
> > It seems bogus (unnecessary) to me.
> 
> I use this feature regularly when copy-pasting revnums from log
> messages, the #svn-dev channel, email, viewvc, etc. into the command
> line. Maybe depending on how I move the mouse and the 'r' becomes
> part of the paste buffer or maybe it doesn't. Some of these consider
> 'r' part of the "word" when I double click the revnum to mark it
> for copy-pasting. Some don't. For some the double-click doesn't work.
> 
> It is really convenient to just type -r into the terminal and then
> paste the number knowing that it will just work for all these cases.
> 
> I think the case Karl meant was there a script gets 123 as input
> and outputs r123?

I wasn't clear.  I'm +1 on allowing an optional 'r' prefix to the
revision number so that your use case and all of these will work:

  svn log -r 123
  svn log -r r123
  svn log -rr123   # parsed the same as -r r123
  svn log --revision 123
  svn log --revision r123
  svn log -c 123
  svn log -c r123
  etc.

but I'm -0.9 on allowing more than one additional prefix:

  svn log -r rr123
  svn log -crrrrrr123
  etc.

because no sensible use case including yours requires this.  However, as
it's been allowed for some time now and it's pretty harmless, we
probably want to keep any-number-of-r's supported.

- Julian



Mime
View raw message