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
Received on 2015-02-16 12:57:53 CET