Op 16-feb.-2015 12:57 schreef "Branko Čibej" <brane_at_wandisco.com>:
>
> On 16.02.2015 12:07, Julian Foad wrote:
> > Branko Čibej wrote:
> >>> * 4556 Replace 'svn youngest' with another UI
> >>> Not much discussion here. I propose we do either option 2
('svnmucc
> >>> youngest'), or rip out the subcommand entirely since there are
lots
> >>> of ways to the info.
> >> I'm going to have a go at an alternative solution; see
> >> ^/subversion/branches/svn-info-detail/BRANCH-README
> > +1 to that.
> >
> > For easier visibility, here's a copy of the BRANCH-README:
> >
> > [[[
> > This branch will be used to implement an alternative solution for
> > the problem described in issue #4299 in order to solve issue #4556.
> >
> > Instead of 'svn youngest', we'll implement an extension to 'svn info',
> > as described in option 1. of issue #4556, as follows:
> >
> > - Add a --detail=FIELD option to 'svn info' that will cause it to
> > display only the value of FIELD and nothing else; for example:
> >
> > $ svn info ^/subversion/trunk --detail=revision 1660035
> > $ svn info ^/subversion/trunk --detail=last-changed-rev 1660014
> >
> > and so on.
> >
> > - The --detail option is incompatible with the --xml option
> >
> > - Initially, only a few field values will be supported with
> > --detail; revision, last-changed-rev, url, relative-url,
> > repository-root; maybe a few more.
> >
> > - The 'svn youngest' command will be removed.
> > ]]]
> >
> > Hooray, more command-line UI designing.
> >
> > I'm not going to bikeshed about the option name, but how should we
choose the spelling of the option values (like "=last-changed-rev")?
>
> --show-value? --get-detail? --print-just-the-following-bit-of-info?
> --cerilean-bikeshed-com?
>
> :)
>
> > * Match the keys of the plain "svn info" output?
> >
> > * Match the XML element/attribute names?
> >
> > * Choose the argument values independently of existing (XML and
plain) outputs?
> >
> > If we match the keys of the plain "svn info" output, would that be in
the current locale or the C locale or both, and with spaces (optionally?)
translated to "-"? Lower case?
> >
> > --detail=revision -> 123
> > --detail=last-changed-rev -> 456
> > --detail=last-changed-author -> me
> >
> > The XML element/attribute names are locale-independent, which is good
for scripting, and simple to implement. On the down side, they are nested:
<entry revision="123">...<commit
revision="456"><author>me</author></commit></entry>, so we might have
(always within an <entry>)
> >
> > --detail=#revision -> 123
> > --detail=commit#revision -> 456
> > --detail=commit.author -> me
> >
> > Or simplify the syntax to use "-" always as the separator between
elements and/or attributes, assuming we won't have any that clash:
> >
> > --detail=revision -> 123
> > --detail=commit-revision -> 456
> > --detail=commit-author -> me
> >
> > Choosing an independent set of fixed identifiers is in some ways the
easiest approach, but is that just because it requires the least thought at
the design stage? We'd make them non-localized, for scripting purposes, I
assume?
>
> Definitely non-localized; we don't localize option names, so we
> shouldn't localize these tokens, either.
>
> At first I thought I'd just lowercase the untranslated keys that 'svn
> info' displays, replacing spaces with dashes. But there's a strong case
> for using the same names as the --xml output; not because it's easier to
> implement, but because it's at least marginally consistent with
> something we already have.
>
> -- Brane
I've never used --xml, but I regularly use the command line. To me
"commit-revision" looks quite alien, but "last-changed-rev" is instantly
familiar. I think there are a lot more cli users than --xml users, so the
first option (using the untranslated lowercased dashes-for-spaces keys of
'svn info') looks better to me.
Just my 2 cents ...
--
Johan
Received on 2015-02-16 18:24:26 CET