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
