You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2015/02/16 12:07:55 UTC
svn info --detail [was: Time to branch 1.9]
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")?
* 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?
- Julian
Re: svn info --show-item [was: svn info --detail]
Posted by Julian Foad <ju...@btopenworld.com>.
I (Julian Foad) wrote:
> +1. Please merge.
I now see Brane merged it earlier today in r1662620.
- Julian
Re: svn info --show-item [was: svn info --detail]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> On 24.02.2015 19:20, Branko Čibej wrote:
>> On 24.02.2015 17:32, Julian Foad wrote:
>>> I'm +1 on merging to trunk. I tried it out briefly and noted a few
>>> minor issues on IRC, none of which would need to be fixed before merging.
>>
>> I believe I fixed those in r1662068 and r1662072.
>>
>> Still need to write some tests for the new feature, though.
>
> I added a number of test cases in r1662199. I'm done with that branch
> now, unless someone finds a nasty bug that would prevent merging to trunk.
+1. Please merge.
- Julian
Merge the svn-info-detail branch to trunk and 1.9.x?
Posted by Branko Čibej <br...@wandisco.com>.
On 25.02.2015 12:22, Branko Čibej wrote:
> On 24.02.2015 19:20, Branko Čibej wrote:
>> On 24.02.2015 17:32, Julian Foad wrote:
>>> Branko Čibej wrote:
>>>> This is what's currently on the branch:
>>>>
>>>> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
>>>> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
>>> [...]
>>>> svn info --show-item=KEYWORD
>>> Looks good to me.
>>>
>>>
>>> I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
>> I believe I fixed those in r1662068 and r1662072.
>>
>> Still need to write some tests for the new feature, though.
> I added a number of test cases in r1662199. I'm done with that branch
> now, unless someone finds a nasty bug that would prevent merging to trunk.
I think the svn-info-detail branch is now as complete as it can
reasonably be at this point. The diff is:
svn diff http://svn.apache.org/repos/asf/subversion/trunk@1662233 \
http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
If there are no objections, I'll merge this to trunk in time for the
catch-up merge to 1.9.x.
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 24.02.2015 19:20, Branko Čibej wrote:
> On 24.02.2015 17:32, Julian Foad wrote:
>> Branko Čibej wrote:
>>> This is what's currently on the branch:
>>>
>>> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
>>> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
>> [...]
>>> svn info --show-item=KEYWORD
>> Looks good to me.
>>
>>
>> I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
> I believe I fixed those in r1662068 and r1662072.
>
> Still need to write some tests for the new feature, though.
I added a number of test cases in r1662199. I'm done with that branch
now, unless someone finds a nasty bug that would prevent merging to trunk.
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 24.02.2015 17:32, Julian Foad wrote:
> Branko Čibej wrote:
>> This is what's currently on the branch:
>>
>> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
>> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
> [...]
>> svn info --show-item=KEYWORD
> Looks good to me.
>
>
> I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
I believe I fixed those in r1662068 and r1662072.
Still need to write some tests for the new feature, though.
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Feb 25, 2015 at 11:16 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 25.02.2015 10:56, Johan Corveleyn wrote:
>> On Tue, Feb 24, 2015 at 5:32 PM, Julian Foad <ju...@btopenworld.com> wrote:
>>> Branko Čibej wrote:
>>>> This is what's currently on the branch:
>>>>
>>>> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
>>>> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
>>> [...]
>>>> svn info --show-item=KEYWORD
>>> Looks good to me.
>>>
>>>
>>> I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
>>>
>>> I'd be happy for this to be ported into 1.9.0 too.
>>>
>> +1. Very nice feature.
>>
>> I've been wondering though (sorry, haven't read through the source,
>> just thinking about how it works): does it support multiple
>> --show-item options? As in:
>>
>> $ svn info --show-item=last-changed-rev
>> --show-item=last-changed-author TARGET
>> 12345
>> johndoe
>>
>> I don't know how this would work together with multple (or recursive)
>> targets, but maybe something like this might be okay:
>>
>> $ svn info --show-item=last-changed-rev
>> --show-item=last-changed-author --depth=immediates .
>> 12345 johndoe .
>> 54321 jrandom README
>> ...
>>
>> ?
>
> No, it doesn't support multiple --show-item options. There are a several
> reasons for that:
>
> * The first is a design decision from day one that we won't complicate
> the command-line client by supporting multiple instances of the same
> option. There's no code for that currently, although I think it
> should be possible to change the option parser to support that.
Ah, but there is precedent for this (otherwise I wouldn't have come up
with the question :-)):
[[[
C:\>svn log -c 1662072 -c 1662177 http://svn.apache.org/repos/asf/subversion/
------------------------------------------------------------------------
r1662072 | brane | 2015-02-24 19:17:59 +0100 (di, 24 feb 2015) | 6 lines
On the svn-info-detail branch: Update help docs for 'svn info'.
* subversion/svn/svn.c
(svn_cl__cmd_table): Fix a typo and improve wording in the
help text of the 'info' command.
------------------------------------------------------------------------
r1662177 | brane | 2015-02-25 09:15:39 +0100 (wo, 25 feb 2015) | 1 line
On the reuse-ra-session branch: Sync with trunk up to r1662176.
------------------------------------------------------------------------
]]]
(or -c 1662072,1662177 works just as well).
I'm using this feature of 'svn log' (added in 1.6 I believe) from some
scripts, because it's a lot faster than invoking 'svn log' multiple
times if you have a set of revs.
> * As you note, there are potential problems with the output format.
> Since --show-item is mainly intended to be used by simple scripts
> (the output is not translated, for example), allowing multiple
> values for one invocation would insanely complicate result parsing
> and we'd probably have to invent whitespace escaping for the values.
> This is already a potential problem with multiple targets.
>
> I think that anyone who needs that level of control in a script should
> just use the bindings and call svn_client_info() directly. After all,
> calling 'svn info --show-item' several times isn't that hard, and not
> appreciably slower for local paths.
Ack, it might be overkill. Just wanted to note / ask about the
possibility. And I guess such an extension, should one go for it, can
always be added later.
Thanks.
--
Johan
Re: svn info --show-item [was: svn info --detail]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Johan Corveleyn wrote:
>> +1. Very nice feature.
>>
>> I've been wondering though (sorry, haven't read through the source,
>> just thinking about how it works): does it support multiple
>> --show-item options? As in:
>>
>> $ svn info --show-item=last-changed-rev --show-item=last-changed-author TARGET
>> 12345
>> johndoe
Currently it sees only the last --show-item option on the command line and ignores any others.
>> I don't know how this would work together with multple (or recursive)
>> targets, but maybe something like this might be okay:
>>
>> $ svn info --show-item=last-changed-rev
>> --show-item=last-changed-author --depth=immediates .
>> 12345 johndoe .
>> 54321 jrandom README
>> ...
>>
>> ?
> No, it doesn't support multiple --show-item options. There are a several
> reasons for that:
>
> * The first is a design decision from day one that we won't complicate
> the command-line client by supporting multiple instances of the same
> option. There's no code for that currently, [...]
Actually, several options already support multiple instances: --with-revprop, --search, ...
Multiple items need not require multiple options anyway:
--show-item=last-changed-rev,last-changed-author
> * As you note, there are potential problems with the output format.
> Since --show-item is mainly intended to be used by simple scripts
> (the output is not translated, for example), allowing multiple
> values for one invocation would insanely complicate result parsing
> and we'd probably have to invent whitespace escaping for the values.
> This is already a potential problem with multiple targets.
The output escaping/parsing issues are basically the same as for 'svn list -v' and 'svn status -v'. Here's a flexible possibility, shown by examples:
# similar to 'svn status -v'
svn info --show-item='%8{revision} %8{last-changed-rev} %-12{last-changed-author}'
1662195 1662137 rhuijben .
# similar to 'svn ls -v'
svn info --show-item='%7{last-changed-rev} %-8.8{last-changed-author} %10{file-size} %12{last-changed-date}'
1662137 rhuijben 2015-02-24T23:06:53.819595Z
But, while all that might be nice, the main aim of this feature was to have an easy way to answer questions such as:
'is this a trunk WC or a branch WC?'
$ svn info --show-item=relative-url .
^/subversion/trunk
'what is the URL of this working copy's repository?'
$ svn info --show-item=repos-root-url .
https://svn.apache.org/repos/asf
'what is the youngest revision in the repository?'
$ svn info --show-item=revision ^/
1662196
- Julian
Re: svn info --show-item [was: svn info --detail]
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Feb 25, 2015 at 11:16:55AM +0100, Branko Čibej wrote:
> I think that anyone who needs that level of control in a script should
> just use the bindings and call svn_client_info() directly.
Or use the --xml option.
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 25.02.2015 10:56, Johan Corveleyn wrote:
> On Tue, Feb 24, 2015 at 5:32 PM, Julian Foad <ju...@btopenworld.com> wrote:
>> Branko Čibej wrote:
>>> This is what's currently on the branch:
>>>
>>> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
>>> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
>> [...]
>>> svn info --show-item=KEYWORD
>> Looks good to me.
>>
>>
>> I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
>>
>> I'd be happy for this to be ported into 1.9.0 too.
>>
> +1. Very nice feature.
>
> I've been wondering though (sorry, haven't read through the source,
> just thinking about how it works): does it support multiple
> --show-item options? As in:
>
> $ svn info --show-item=last-changed-rev
> --show-item=last-changed-author TARGET
> 12345
> johndoe
>
> I don't know how this would work together with multple (or recursive)
> targets, but maybe something like this might be okay:
>
> $ svn info --show-item=last-changed-rev
> --show-item=last-changed-author --depth=immediates .
> 12345 johndoe .
> 54321 jrandom README
> ...
>
> ?
No, it doesn't support multiple --show-item options. There are a several
reasons for that:
* The first is a design decision from day one that we won't complicate
the command-line client by supporting multiple instances of the same
option. There's no code for that currently, although I think it
should be possible to change the option parser to support that.
* As you note, there are potential problems with the output format.
Since --show-item is mainly intended to be used by simple scripts
(the output is not translated, for example), allowing multiple
values for one invocation would insanely complicate result parsing
and we'd probably have to invent whitespace escaping for the values.
This is already a potential problem with multiple targets.
I think that anyone who needs that level of control in a script should
just use the bindings and call svn_client_info() directly. After all,
calling 'svn info --show-item' several times isn't that hard, and not
appreciably slower for local paths.
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 24, 2015 at 5:32 PM, Julian Foad <ju...@btopenworld.com> wrote:
> Branko Čibej wrote:
>> This is what's currently on the branch:
>>
>> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
>> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
> [...]
>> svn info --show-item=KEYWORD
>
> Looks good to me.
>
>
> I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
>
> I'd be happy for this to be ported into 1.9.0 too.
>
+1. Very nice feature.
I've been wondering though (sorry, haven't read through the source,
just thinking about how it works): does it support multiple
--show-item options? As in:
$ svn info --show-item=last-changed-rev
--show-item=last-changed-author TARGET
12345
johndoe
I don't know how this would work together with multple (or recursive)
targets, but maybe something like this might be okay:
$ svn info --show-item=last-changed-rev
--show-item=last-changed-author --depth=immediates .
12345 johndoe .
54321 jrandom README
...
?
--
Johan
Re: svn info --show-item [was: svn info --detail]
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> This is what's currently on the branch:
>
> svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
> http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
[...]
> svn info --show-item=KEYWORD
Looks good to me.
I'm +1 on merging to trunk. I tried it out briefly and noted a few minor issues on IRC, none of which would need to be fixed before merging.
I'd be happy for this to be ported into 1.9.0 too.
- Julian
Re: svn info --show-item [was: svn info --detail]
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Fri, Feb 27, 2015 at 21:03:04 +0100:
> On 27.02.2015 18:20, Daniel Shahaf wrote:
> > The
> > intended users are scripts so a longer spelling is not a problem there,
> > either.
>
> I don't oppose the change. We can have both spellings, too.
Okay. I've gone ahead and changed the spelling from last-changed-rev to
last-changed-revision: r1663003. I wouldn't be opposed to supporting
both spellings, but since a reason to support multiple spellings for
a single function has not been identified, I defaulted to unambiguity.
Cheers,
Daniel
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 27.02.2015 18:20, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Feb 24, 2015 at 17:06:00 +0100:
>> On 24.02.2015 17:01, Branko Čibej wrote:
>>> UNLESS there are multiple targets or the operation depth is greater
>>> than 'empty', in which case the output is a pair of (value,
>>> target-path) for each (recursive) target. The target path is either
>>> the (relative or absolute) path of the target or its URL. There is no
>>> provision for whitespace escaping in the value.
>> Here's an example of this format:
>>
>> $ svn info --show-item=last-changed-rev --depth=immediates .
>> 1661934 .
> How about changing "last-changed-rev" to "last-changed-revision"? The
> longer spelling would be self-explanatory and consistent with everything
> else (we don't use the term "rev" anywhere else user-facing).
Yes we do:
$ svn info | grep Rev:
Last Changed Rev: 1662668
> The
> intended users are scripts so a longer spelling is not a problem there,
> either.
I don't oppose the change. We can have both spellings, too.
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Tue, Feb 24, 2015 at 17:06:00 +0100:
> On 24.02.2015 17:01, Branko Čibej wrote:
> > UNLESS there are multiple targets or the operation depth is greater
> > than 'empty', in which case the output is a pair of (value,
> > target-path) for each (recursive) target. The target path is either
> > the (relative or absolute) path of the target or its URL. There is no
> > provision for whitespace escaping in the value.
>
> Here's an example of this format:
>
> $ svn info --show-item=last-changed-rev --depth=immediates .
> 1661934 .
How about changing "last-changed-rev" to "last-changed-revision"? The
longer spelling would be self-explanatory and consistent with everything
else (we don't use the term "rev" anywhere else user-facing). The
intended users are scripts so a longer spelling is not a problem there,
either.
Daniel
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 24.02.2015 17:01, Branko Čibej wrote:
> UNLESS there are multiple targets or the operation depth is greater
> than 'empty', in which case the output is a pair of (value,
> target-path) for each (recursive) target. The target path is either
> the (relative or absolute) path of the target or its URL. There is no
> provision for whitespace escaping in the value.
Here's an example of this format:
$ svn info --show-item=last-changed-rev --depth=immediates .
1661934 .
1242804 README
1661247 build
1661934 subversion
1659395 contrib
915036 BUGS
1661653 tools
1624532 configure.ac
1659546 TODO
1659509 .ycm_extra_conf.py
1586640 doc
1660543 INSTALL
1661245 CHANGES
1659668 autogen.sh
1661247 gen-make.py
1455183 aclocal.m4
1643482 get-deps.sh
1655909 NOTICE
1659236 Makefile.in
1655909 LICENSE
1660874 build.conf
1659509 win-tests.py
1654775 COMMITTERS
1659395 notes
(It's funny, I thought we made some effort to sort directory listings,
but apparently 'svn info' doesn't think so.)
-- Brane
Re: --no-newline vs. --strict
Posted by Branko Čibej <br...@wandisco.com>.
On 25.02.2015 14:22, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> The single usage of the --strict option is arguably complete nonsense:
>> the default docstring, which isn't displayed *anywhere*, is 'use strict
>> semantics' and ... means nothing at all. In actual usage, --strict is
>> hardly mnemonic for not printing trailing newlines.
> --strict originally did more. r845498, in 1.0, shows that --strict
> originally stripped both the the path prefix and the newline. r872554,
> in 1.6, limited --strict to a single path at which point it just
> stripped newlines.
>
>> Given all that, I propose we deprecate --strict and conflate the actual
>> option value with --no-newline, like this (this is trunk, untested):
> That looks like a good solution.
r1662224
-- Brane
Re: --no-newline vs. --strict
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>> The single usage of the --strict option is arguably complete nonsense:
>> the default docstring, which isn't displayed *anywhere*, is 'use strict
>> semantics' and ... means nothing at all. In actual usage, --strict is
>> hardly mnemonic for not printing trailing newlines.
>
> --strict originally did more. r845498, in 1.0, shows that --strict
> originally stripped both the the path prefix and the newline. r872554,
> in 1.6, limited --strict to a single path at which point it just
> stripped newlines.
>
>> Given all that, I propose we deprecate --strict and conflate the actual
>> option value with --no-newline, like this (this is trunk, untested):
>
> That looks like a good solution.
+1.
See also a previous discussion thread "--strict vs --no-newline", started 2014-06-09, <http://svn.haxx.se/dev/archive-2014-06/0023.shtml>, <http://mail-archives.apache.org/mod_mbox/subversion-dev/201406.mbox/%3C1402331950.91045.YahooMailNeo@web87705.mail.ir2.yahoo.com%3E>.
- Julian
Re: --no-newline vs. --strict
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> The single usage of the --strict option is arguably complete nonsense:
> the default docstring, which isn't displayed *anywhere*, is 'use strict
> semantics' and ... means nothing at all. In actual usage, --strict is
> hardly mnemonic for not printing trailing newlines.
--strict originally did more. r845498, in 1.0, shows that --strict
originally stripped both the the path prefix and the newline. r872554,
in 1.6, limited --strict to a single path at which point it just
stripped newlines.
> Given all that, I propose we deprecate --strict and conflate the actual
> option value with --no-newline, like this (this is trunk, untested):
That looks like a good solution.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
--no-newline vs. --strict
Posted by Branko Čibej <br...@wandisco.com>.
On 25.02.2015 12:34, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 25.02.2015 12:10, Philip Martin wrote:
>>> Branko Čibej <br...@wandisco.com> writes:
>>>
>>>> The new variant of 'svn info' is called
>>>>
>>>> svn info --show-item=KEYWORD
>>>>
>>>> (it also accepts --no-newline, just like 'svn youngest' did).
>>> 'svn propget' has a much longer history of using --strict to suppress
>>> the newline.
>> Yes, but what are you suggesting, that I add the '--strict' option to
>> 'svn info'? Because I have trouble imagining how that would be
>> understandable to users.
> I am suggesting that --no-newline should be replaced by --strict. Is it
> harder to understand when used with 'info' than it is when used with
> 'propget'? It seems odd for different sub-commands to use different
> names for what is essentially the same option.
>
> 'svn youngest' is not a precedent for using --no-newline in 'svn' as it
> was never released. 'svnversion' does use '--no-newline' but it is not
> 'svn' and it also has '-c' that conflicts with 'svn'.
I'm changing the subject here because this --no-newline vs. --strict
debate really has nothing to do with 'svn info --show-item'.
To illustrate how absurd the current state is (this is on the
svn-info-detail branch):
$ grep -n opt_no_newline subversion/svn/svn.c
146: opt_no_newline,
421: {"no-newline", opt_no_newline, 0, N_("do not output the trailing newline")},
759: opt_changelist, opt_include_externals, opt_show_item, opt_no_newline}
2418: case opt_no_newline:
$ grep -n opt_strict subversion/svn/svn.c
113: opt_strict,
236: {"strict", opt_strict, 0, N_("use strict semantics")},
1380: {'v', 'R', opt_depth, 'r', opt_revprop, opt_strict, opt_xml,
1383: {opt_strict, N_("don't print an extra newline")}} },
2175: case opt_strict:
We have two options, one called --strict and another called --no-newline
(the latter is new on trunk). Both are used exactly once.
The single usage of the --strict option is arguably complete nonsense:
the default docstring, which isn't displayed *anywhere*, is 'use strict
semantics' and ... means nothing at all. In actual usage, --strict is
hardly mnemonic for not printing trailing newlines.
Given all that, I propose we deprecate --strict and conflate the actual
option value with --no-newline, like this (this is trunk, untested):
[[[
Index: subversion/svn/cl.h
===================================================================
--- subversion/svn/cl.h (revision 1662202)
+++ subversion/svn/cl.h (working copy)
@@ -167,7 +167,6 @@ typedef struct svn_cl__opt_state_t
svn_boolean_t version; /* print version information */
svn_boolean_t verbose; /* be verbose */
svn_boolean_t update; /* contact the server for the full story */
- svn_boolean_t strict; /* do strictly what was requested */
svn_stringbuf_t *filedata; /* contents of file used as option data
(not converted to UTF-8) */
const char *encoding; /* the locale/encoding of 'message' and of
Index: subversion/svn/propget-cmd.c
===================================================================
--- subversion/svn/propget-cmd.c (revision 1662202)
+++ subversion/svn/propget-cmd.c (working copy)
@@ -322,11 +322,11 @@ svn_cl__propget(apr_getopt_t *os,
svn_stream_t *out;
svn_boolean_t warned = FALSE;
- if (opt_state->verbose && (opt_state->revprop || opt_state->strict
+ if (opt_state->verbose && (opt_state->revprop || opt_state->no_newline
|| opt_state->xml))
return svn_error_create(SVN_ERR_CL_MUTUALLY_EXCLUSIVE_ARGS, NULL,
_("--verbose cannot be used with --revprop or "
- "--strict or --xml"));
+ "--no-newline or --xml"));
/* PNAME is first argument (and PNAME_UTF8 will be a UTF-8 version
thereof) */
@@ -411,7 +411,7 @@ svn_cl__propget(apr_getopt_t *os,
SVN_ERR(stream_write(out, printable_val->data,
printable_val->len));
- if (! opt_state->strict)
+ if (! opt_state->no_newline)
SVN_ERR(stream_write(out, APR_EOL_STR, strlen(APR_EOL_STR)));
}
}
@@ -427,16 +427,17 @@ svn_cl__propget(apr_getopt_t *os,
if (opt_state->depth == svn_depth_unknown)
opt_state->depth = svn_depth_empty;
- /* Strict mode only makes sense for a single target. So make
+ /* No-newline mode only makes sense for a single target. So make
sure we have only a single target, and that we're not being
asked to recurse on that target. */
- if (opt_state->strict
+ if (opt_state->no_newline
&& ((targets->nelts > 1) || (opt_state->depth != svn_depth_empty)
|| (opt_state->show_inherited_props)))
return svn_error_create
(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
- _("Strict output of property values only available for single-"
- "target, non-recursive propget operations"));
+ _("Output of property values without a trailing newline"
+ " is only available for single-target, non-recursive"
+ " propget operations"));
for (i = 0; i < targets->nelts; i++)
{
@@ -472,15 +473,15 @@ svn_cl__propget(apr_getopt_t *os,
/* Any time there is more than one thing to print, or where
the path associated with a printed thing is not obvious,
we'll print filenames. That is, unless we've been told
- not to do so with the --strict option. */
+ not to do so with the --no-newline option. */
print_filenames = ((opt_state->depth > svn_depth_empty
|| targets->nelts > 1
|| apr_hash_count(props) > 1
|| opt_state->verbose
|| opt_state->show_inherited_props)
- && (! opt_state->strict));
- omit_newline = opt_state->strict;
- like_proplist = opt_state->verbose && !opt_state->strict;
+ && (! opt_state->no_newline));
+ omit_newline = opt_state->no_newline;
+ like_proplist = opt_state->verbose && !opt_state->no_newline;
/* If there are no properties, and exactly one node was queried,
then warn. */
Index: subversion/svn/svn.c
===================================================================
--- subversion/svn/svn.c (revision 1662202)
+++ subversion/svn/svn.c (working copy)
@@ -110,7 +110,7 @@ typedef enum svn_cl__longopt_t {
opt_remove,
opt_revprop,
opt_stop_on_copy,
- opt_strict,
+ opt_strict, /* ### DEPRECATED */
opt_targets,
opt_depth,
opt_set_depth,
@@ -232,7 +232,7 @@ const apr_getopt_option_t svn_cl__options[] =
" "
"'empty', 'files', 'immediates', or 'infinity')")},
{"xml", opt_xml, 0, N_("output in XML")},
- {"strict", opt_strict, 0, N_("use strict semantics")},
+ {"strict", opt_strict, 0, N_("DEPRECATED")},
{"stop-on-copy", opt_stop_on_copy, 0,
N_("do not cross copies while traversing history")},
{"no-ignore", opt_no_ignore, 0,
@@ -1355,14 +1355,14 @@ const svn_opt_subcommand_desc2_t svn_cl__cmd_table
"\n"
" By default, an extra newline is printed after the property value so that\n"
" the output looks pretty. With a single TARGET, depth 'empty' and without\n"
- " --show-inherited-props, you can use the --strict option to disable this\n"
+ " --show-inherited-props, you can use the --no-newline option to disable this\n"
" (useful when redirecting a binary property value to a file, for example).\n"
"\n"
" See 'svn help propset' for descriptions of the svn:* special properties.\n"),
- {'v', 'R', opt_depth, 'r', opt_revprop, opt_strict, opt_xml,
+ {'v', 'R', opt_depth, 'r', opt_revprop, opt_strict, opt_no_newline, opt_xml,
opt_changelist, opt_show_inherited_props },
{{'v', N_("print path, name and value on separate lines")},
- {opt_strict, N_("don't print an extra newline")}} },
+ {opt_strict, N_("(deprecated; use --no-newline)")}} },
{ "proplist", svn_cl__proplist, {"plist", "pl"}, N_
("List all properties on files, dirs, or revisions.\n"
@@ -2154,9 +2154,6 @@ sub_main(int *exit_code, int argc, const char *arg
case opt_stop_on_copy:
opt_state.stop_on_copy = TRUE;
break;
- case opt_strict:
- opt_state.strict = TRUE;
- break;
case opt_no_ignore:
opt_state.no_ignore = TRUE;
break;
@@ -2398,6 +2395,7 @@ sub_main(int *exit_code, int argc, const char *arg
opt_state.remove_ignored = TRUE;
break;
case opt_no_newline:
+ case opt_strict: /* ### DEPRECATED */
opt_state.no_newline = TRUE;
break;
case opt_show_passwords:
Index: subversion/tests/cmdline/checkout_tests.py
===================================================================
--- subversion/tests/cmdline/checkout_tests.py (revision 1662202)
+++ subversion/tests/cmdline/checkout_tests.py (working copy)
@@ -662,7 +662,7 @@ def checkout_peg_rev_date(sbox):
## Get svn:date.
exit_code, output, errput = svntest.main.run_svn(None, 'propget', 'svn:date',
'--revprop', '-r1',
- '--strict',
+ '--no-newline',
sbox.repo_url)
if exit_code or errput != [] or len(output) != 1:
raise svntest.Failure("svn:date propget failed")
Index: subversion/tests/cmdline/prop_tests.py
===================================================================
--- subversion/tests/cmdline/prop_tests.py (revision 1662202)
+++ subversion/tests/cmdline/prop_tests.py (working copy)
@@ -2611,7 +2611,7 @@ def peg_rev_base_working(sbox):
sbox.simple_commit(message='r2')
svntest.actions.set_prop('cardinal', 'nine\n', sbox.ospath('iota'))
svntest.actions.run_and_verify_svn(['ninth\n'], [],
- 'propget', '--strict', 'ordinal',
+ 'propget', '--no-newline', 'ordinal',
sbox.ospath('iota') + '@BASE')
@Issue(4415)
@@ -2644,7 +2644,7 @@ def xml_unsafe_author(sbox):
# a single property value which skips creating the creator-displayname property
svntest.actions.run_and_verify_svn(['foo\bbar'], [],
'propget', '--revprop', '-r', '1',
- 'svn:author', '--strict', wc_dir)
+ 'svn:author', '--no-newline', wc_dir)
# Ensure a stable date
svntest.actions.run_and_verify_svn(None, [],
Index: subversion/tests/cmdline/special_tests.py
===================================================================
--- subversion/tests/cmdline/special_tests.py (revision 1662202)
+++ subversion/tests/cmdline/special_tests.py (working copy)
@@ -705,7 +705,7 @@ def propvalue_normalized(sbox):
# Property value should be SVN_PROP_BOOLEAN_TRUE
expected_propval = ['*']
svntest.actions.run_and_verify_svn(expected_propval, [],
- 'propget', '--strict', 'svn:special',
+ 'propget', '--no-newline', 'svn:special',
iota2_path)
# Commit and check again.
@@ -722,7 +722,7 @@ def propvalue_normalized(sbox):
svntest.main.run_svn(None, 'update', wc_dir)
svntest.actions.run_and_verify_svn(expected_propval, [],
- 'propget', '--strict', 'svn:special',
+ 'propget', '--no-newline', 'svn:special',
iota2_path)
Index: subversion/tests/cmdline/svnmucc_tests.py
===================================================================
--- subversion/tests/cmdline/svnmucc_tests.py (revision 1662202)
+++ subversion/tests/cmdline/svnmucc_tests.py (working copy)
@@ -345,7 +345,7 @@ def propset_root_internal(sbox, target):
'propset', 'foo', 'bar',
target)
svntest.actions.run_and_verify_svn('bar', [],
- 'propget', '--strict', 'foo',
+ 'propget', '--no-newline', 'foo',
target)
## propdel on ^/
@@ -355,7 +355,7 @@ def propset_root_internal(sbox, target):
target)
svntest.actions.run_and_verify_svn([],
'.*W200017: Property.*not found',
- 'propget', '--strict', 'foo',
+ 'propget', '--no-newline', 'foo',
target)
@Issues(3663)
Index: subversion/tests/cmdline/trans_tests.py
===================================================================
--- subversion/tests/cmdline/trans_tests.py (revision 1662202)
+++ subversion/tests/cmdline/trans_tests.py (working copy)
@@ -680,7 +680,7 @@ def cat_keyword_expansion(sbox):
sbox.wc_dir)
svntest.actions.run_and_verify_svn([ full_author ], [],
'propget', '--revprop', '-r2',
- 'svn:author', '--strict',
+ 'svn:author', '--no-newline',
sbox.wc_dir)
# Make another commit so that the last changed revision for A/mu is
]]]
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 25.02.2015 12:10, Philip Martin wrote:
>> Branko Čibej <br...@wandisco.com> writes:
>>
>>> The new variant of 'svn info' is called
>>>
>>> svn info --show-item=KEYWORD
>>>
>>> (it also accepts --no-newline, just like 'svn youngest' did).
>> 'svn propget' has a much longer history of using --strict to suppress
>> the newline.
>
> Yes, but what are you suggesting, that I add the '--strict' option to
> 'svn info'? Because I have trouble imagining how that would be
> understandable to users.
I am suggesting that --no-newline should be replaced by --strict. Is it
harder to understand when used with 'info' than it is when used with
'propget'? It seems odd for different sub-commands to use different
names for what is essentially the same option.
'svn youngest' is not a precedent for using --no-newline in 'svn' as it
was never released. 'svnversion' does use '--no-newline' but it is not
'svn' and it also has '-c' that conflicts with 'svn'.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 25.02.2015 12:10, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> The new variant of 'svn info' is called
>>
>> svn info --show-item=KEYWORD
>>
>> (it also accepts --no-newline, just like 'svn youngest' did).
> 'svn propget' has a much longer history of using --strict to suppress
> the newline.
Yes, but what are you suggesting, that I add the '--strict' option to
'svn info'? Because I have trouble imagining how that would be
understandable to users.
-- Brane
Re: svn info --show-item [was: svn info --detail]
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> The new variant of 'svn info' is called
>
> svn info --show-item=KEYWORD
>
> (it also accepts --no-newline, just like 'svn youngest' did).
'svn propget' has a much longer history of using --strict to suppress
the newline.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn info --show-item [was: svn info --detail]
Posted by Branko Čibej <br...@wandisco.com>.
On 16.02.2015 12:07, Julian Foad wrote:
> Hooray, more command-line UI designing.
This is what's currently on the branch:
svn diff http://svn.apache.org/repos/asf/subversion/trunk@1661975 \
http://svn.apache.org/repos/asf/subversion/branches/svn-info-detail
You can safely ignore the changes in the following files:
* subversion/include/private/svn_string_private.h
* subversion/libsvn_subr/string.c
* subversion/tests/libsvn_subr/string-test.c
* subversion/svn/similarity.c
* subversion/svn/props.c
because they're just an abstraction of the string similarity check code
that was formerly used only by propset/propedit.
The new variant of 'svn info' is called
svn info --show-item=KEYWORD
(it also accepts --no-newline, just like 'svn youngest' did).
The keywords currently supported are: kind, url, relative-url,
repos-root-url, repos-uuid, revision, last-changed-rev,
last-changed-date, last-changed-author and wc-root. They should be
pretty much self-explanatory.
The output of the command is just the single requested value, with or
without a trailing newline, UNLESS there are multiple targets or the
operation depth is greater than 'empty', in which case the output is a
pair of (value, target-path) for each (recursive) target. The target
path is either the (relative or absolute) path of the target or its URL.
There is no provision for whitespace escaping in the value.
Right now, the code raises an error if someone requests the wc-root of
something that's not in a working copy. I'm considering changing that to
simply output nothing at all instead.
-- Brane
RE: svn info --detail [was: Time to branch 1.9]
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@wandisco.com]
> Sent: dinsdag 17 februari 2015 10:51
> To: dev@subversion.apache.org
> Subject: Re: svn info --detail [was: Time to branch 1.9]
>
> On 17.02.2015 10:29, Julian Foad wrote:
> > Ben Reser wrote:
> >> On 2/16/15 3:57 AM, Branko Čibej wrote:
> >>> 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.
> >> The XML names are pretty bad in my opinion. These are the two blocks out
> of
> >> the XML output that have the current revision and the last changed revision
> >> respectively:
> > I don't necessarily disagree with your conclusion, but want to correct the
> facts.
> >
> >> [[[
> >> <entry
> >> kind="file"
> >> path="install.sh"
> >> revision="148">
> >> <commit
> >> revision="35">
> > ... </commit>
> > ... </entry>
> >
> >> ]]]
> >>
> >> I think command line users are going to find the distinction between
> >> "entry-revision" and "commit-revision" to be obscure.
> > In our XML output, the <entry> element is the wrapper for the whole of the
> info for one target, and is thus redundant in these specifications. These two
> would be "revision" and "commit-revision".
> >
> >> Entry is leakage from our WC data model leaking into the XML output,
> where it
> >> really doesn't belong.
> > I don't think it is: rather, it is just saying in the most general sense that this is
> one entry in a list. Compare the other XML outputs (most easily seen by
> examining subversion/svn/schema/*.rnc) where "entry" is used for the element
> of various kinds of lists -- lines of blame, targets of status, etc.
> >
> >> The XML values taken literally would also be way more verbose than
> necessary.
> >> "entry-path" versus just "path".
> > This one would be just "path".
> >
> >> For that matter are you going to keep some of the parent blocks like "wc-
> info"
> >> which would make things like "schedule" into "wc-info-schedule"
> >>
> >> The repository root key would end up being "entry-repository-root" if you
> kept
> >> the nesting as well.
> > Just "repository-root".
> >
> >> So in my opinion just using the untranslated info keys with spaces turned into
> >> "-" is far better.
> >>
> >> You're almost certainly going to end up making arbitrary decisions anyway
> since
> >> some of the names start getting silly.
>
> For now, I'd only expose the attributes of <entry> and <commit> and the
> elements within <commit> and <repository>, along with the URLs. The
> definitive list is:
>
> revision
> kind
> url
> relative-url
> repository-root
> repository-uuid
> commit-revision
> commit-author
> commit-date
>
> I wouldn't expose entry's 'path' attribute because it doesn't make much
> sense; in the WC case, it's already known and in the URL case, it's
> always the basename, which is also known. I'd also leave wc-info,
> conflicts etc. out for now.
>
>
> All that said: Johan makes a good point about using keywords that are
> more likely to be familiar to users; the XML-based ones are far from that.
I paint my shed in the 'last-revision', 'last-author' and 'last-date' color...
(Following Johan's suggestion and all recent code in libsvn_wc)
Bert
Re: svn info --detail [was: Time to branch 1.9]
Posted by Branko Čibej <br...@wandisco.com>.
On 17.02.2015 10:29, Julian Foad wrote:
> Ben Reser wrote:
>> On 2/16/15 3:57 AM, Branko Čibej wrote:
>>> 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.
>> The XML names are pretty bad in my opinion. These are the two blocks out of
>> the XML output that have the current revision and the last changed revision
>> respectively:
> I don't necessarily disagree with your conclusion, but want to correct the facts.
>
>> [[[
>> <entry
>> kind="file"
>> path="install.sh"
>> revision="148">
>> <commit
>> revision="35">
> ... </commit>
> ... </entry>
>
>> ]]]
>>
>> I think command line users are going to find the distinction between
>> "entry-revision" and "commit-revision" to be obscure.
> In our XML output, the <entry> element is the wrapper for the whole of the info for one target, and is thus redundant in these specifications. These two would be "revision" and "commit-revision".
>
>> Entry is leakage from our WC data model leaking into the XML output, where it
>> really doesn't belong.
> I don't think it is: rather, it is just saying in the most general sense that this is one entry in a list. Compare the other XML outputs (most easily seen by examining subversion/svn/schema/*.rnc) where "entry" is used for the element of various kinds of lists -- lines of blame, targets of status, etc.
>
>> The XML values taken literally would also be way more verbose than necessary.
>> "entry-path" versus just "path".
> This one would be just "path".
>
>> For that matter are you going to keep some of the parent blocks like "wc-info"
>> which would make things like "schedule" into "wc-info-schedule"
>>
>> The repository root key would end up being "entry-repository-root" if you kept
>> the nesting as well.
> Just "repository-root".
>
>> So in my opinion just using the untranslated info keys with spaces turned into
>> "-" is far better.
>>
>> You're almost certainly going to end up making arbitrary decisions anyway since
>> some of the names start getting silly.
For now, I'd only expose the attributes of <entry> and <commit> and the
elements within <commit> and <repository>, along with the URLs. The
definitive list is:
revision
kind
url
relative-url
repository-root
repository-uuid
commit-revision
commit-author
commit-date
I wouldn't expose entry's 'path' attribute because it doesn't make much
sense; in the WC case, it's already known and in the URL case, it's
always the basename, which is also known. I'd also leave wc-info,
conflicts etc. out for now.
All that said: Johan makes a good point about using keywords that are
more likely to be familiar to users; the XML-based ones are far from that.
-- Brane
Re: svn info --detail [was: Time to branch 1.9]
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:
> On 2/16/15 3:57 AM, Branko Čibej wrote:
>> 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.
>
> The XML names are pretty bad in my opinion. These are the two blocks out of
> the XML output that have the current revision and the last changed revision
> respectively:
I don't necessarily disagree with your conclusion, but want to correct the facts.
> [[[
> <entry
> kind="file"
> path="install.sh"
> revision="148">
> <commit
> revision="35">
... </commit>
... </entry>
> ]]]
>
> I think command line users are going to find the distinction between
> "entry-revision" and "commit-revision" to be obscure.
In our XML output, the <entry> element is the wrapper for the whole of the info for one target, and is thus redundant in these specifications. These two would be "revision" and "commit-revision".
> Entry is leakage from our WC data model leaking into the XML output, where it
> really doesn't belong.
I don't think it is: rather, it is just saying in the most general sense that this is one entry in a list. Compare the other XML outputs (most easily seen by examining subversion/svn/schema/*.rnc) where "entry" is used for the element of various kinds of lists -- lines of blame, targets of status, etc.
> The XML values taken literally would also be way more verbose than necessary.
> "entry-path" versus just "path".
This one would be just "path".
> For that matter are you going to keep some of the parent blocks like "wc-info"
> which would make things like "schedule" into "wc-info-schedule"
>
> The repository root key would end up being "entry-repository-root" if you kept
> the nesting as well.
Just "repository-root".
> So in my opinion just using the untranslated info keys with spaces turned into
> "-" is far better.
>
> You're almost certainly going to end up making arbitrary decisions anyway since
> some of the names start getting silly.
- Julian
Re: svn info --detail [was: Time to branch 1.9]
Posted by Ben Reser <be...@reser.org>.
On 2/16/15 3:57 AM, Branko Čibej wrote:
> 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.
The XML names are pretty bad in my opinion. These are the two blocks out of
the XML output that have the current revision and the last changed revision
respectively:
[[[
<entry
kind="file"
path="install.sh"
revision="148">
<commit
revision="35">
]]]
I think command line users are going to find the distinction between
"entry-revision" and "commit-revision" to be obscure.
Entry is leakage from our WC data model leaking into the XML output, where it
really doesn't belong.
The XML values taken literally would also be way more verbose than necessary.
"entry-path" versus just "path".
For that matter are you going to keep some of the parent blocks like "wc-info"
which would make things like "schedule" into "wc-info-schedule"
The repository root key would end up being "entry-repository-root" if you kept
the nesting as well.
So in my opinion just using the untranslated info keys with spaces turned into
"-" is far better.
You're almost certainly going to end up making arbitrary decisions anyway since
some of the names start getting silly.
Re: svn info --detail [was: Time to branch 1.9]
Posted by Johan Corveleyn <jc...@gmail.com>.
Op 16-feb.-2015 12:57 schreef "Branko Čibej" <br...@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
Re: svn info --detail [was: Time to branch 1.9]
Posted by Branko Čibej <br...@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