You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2015/02/24 17:01:07 UTC
Re: svn info --show-item [was: svn info --detail]
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 --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*