You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Fuhrmann <st...@apache.org> on 2017/12/03 21:46:33 UTC
Re: Subversion 1.10 RC1?
On 22.11.2017 15:48, Evgeny Kotkov wrote:
> The other two features that I remember, are:
>
> * improved authz with support for wildcards
>
> * server-side search with `svn ls --search`
>
> Speaking of the `ls --search`, I think that there is an issue with the
> command-line parsing. Based on what I see, the --search argument may
> be interpreted as the target for listing, but not as the search pattern:
>
> svn ls --search *
>
> svn: warning: apr_err=SVN_ERR_WC_PATH_NOT_FOUND
> svn: warning: W155010: The node 'C:\Project\unversioned' was not found.
> ..\..\..\subversion\svn\list-cmd.c:453: (apr_err=SVN_ERR_ILLEGAL_TARGET)
> svn: E200009: Could not list all targets because some targets don't exist
>
> svn ls http://spbvo-ws09.ostyserver.net:8080/svn/master2 --search *
> svn: E155007: 'C:\AnotherProject' is not a working copy
There seems to be little that could be done here (suggestions welcome).
The problem is that the asterisk is being expanded by the shell itself.
I made SVN print its command line parameters and this is the result:
$ ./subversion/svn/svn ls svn://localhost/kde --search M*
0: ./subversion/svn/svn
1: ls
2: svn://localhost/kde
3: --search
4: Makefile
5: Makefile.in
That can be prevented by adding quotation marks:
$ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
0: ./subversion/svn/svn
1: ls
2: svn://localhost/kde
3: --search
4: M*
So, I extended the user docstring accordingly in r1817053.
-- Stefan^2.
Re: Subversion 1.10 RC1?
Posted by Branko Čibej <br...@apache.org>.
On 07.12.2017 17:42, Doug Robinson wrote:
>
> On Wed, Dec 6, 2017 at 7:09 PM, Daniel Shahaf <d.s@daniel.shahaf.name
> <ma...@daniel.shahaf.name>> wrote:
>
> Evgeny Kotkov wrote on Wed, Dec 06, 2017 at 00:12:55 +0300:
> > Unfortunately, on Windows both `--search M*` and (quoted)
> `--search "M*"`
> > would expand the asterisk. While this is not the default shell
> behavior,
> > currently it's enabled for svn and a couple of other binaries by
> linking
> > to setargv.obj. In turn, this probably means the command-line
> client
> > users on Windows could get quite unexpected results when using the
> > `--search ARG` syntax.
>
> Isn't there some escaping syntax, «svn log --search "M^*"» or
> something along
> these lines?
>
>
> Apparently
> not: https://stackoverflow.com/questions/47512829/is-it-possible-to-quote-escape-command-line-arguments-on-windows-while-linking-s
Yes, it's a pity. I _almost_ regret not doing the grunt work for glob
expansion on Windows back in the day. But now that I'm not developing on
Windows, I don't regret it at all. :D
-- Brane
Re: Subversion 1.10 RC1?
Posted by Doug Robinson <do...@wandisco.com>.
On Wed, Dec 6, 2017 at 7:09 PM, Daniel Shahaf <d....@daniel.shahaf.name>
wrote:
> Evgeny Kotkov wrote on Wed, Dec 06, 2017 at 00:12:55 +0300:
> > Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
> > would expand the asterisk. While this is not the default shell behavior,
> > currently it's enabled for svn and a couple of other binaries by linking
> > to setargv.obj. In turn, this probably means the command-line client
> > users on Windows could get quite unexpected results when using the
> > `--search ARG` syntax.
>
> Isn't there some escaping syntax, «svn log --search "M^*"» or something
> along
> these lines?
>
Apparently not:
https://stackoverflow.com/questions/47512829/is-it-possible-to-quote-escape-command-line-arguments-on-windows-while-linking-s
--
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
T +1 925 396 1125
*E* doug.robinson@wandisco.com
--
World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE
PRIVILEGED
If this message was misdirected, WANdisco, Inc. and its subsidiaries,
("WANdisco") does not waive any confidentiality or privilege. If you are
not the intended recipient, please notify us immediately and destroy the
message without disclosing its contents to anyone. Any distribution, use or
copying of this email or the information it contains by other than an
intended recipient is unauthorized. The views and opinions expressed in
this email message are the author's own and may not reflect the views and
opinions of WANdisco, unless the author is authorized by WANdisco to
express such views or opinions on its behalf. All email sent to or from
this address is subject to electronic storage and review by WANdisco.
Although WANdisco operates anti-virus programs, it does not accept
responsibility for any damage whatsoever caused by viruses being passed.
Re: Subversion 1.10 RC1?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Evgeny Kotkov wrote on Wed, Dec 06, 2017 at 00:12:55 +0300:
> Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
> would expand the asterisk. While this is not the default shell behavior,
> currently it's enabled for svn and a couple of other binaries by linking
> to setargv.obj. In turn, this probably means the command-line client
> users on Windows could get quite unexpected results when using the
> `--search ARG` syntax.
Isn't there some escaping syntax, «svn log --search "M^*"» or something along
these lines?
Re: Subversion 1.10 RC1?
Posted by Branko Čibej <br...@apache.org>.
On 05.12.2017 22:12, Evgeny Kotkov wrote:
> Stefan Fuhrmann <st...@apache.org> writes:
>
>> There seems to be little that could be done here (suggestions welcome).
>> The problem is that the asterisk is being expanded by the shell itself.
>> I made SVN print its command line parameters and this is the result:
>>
>> $ ./subversion/svn/svn ls svn://localhost/kde --search M*
>> 0: ./subversion/svn/svn
>> 1: ls
>> 2: svn://localhost/kde
>> 3: --search
>> 4: Makefile
>> 5: Makefile.in
>>
>> That can be prevented by adding quotation marks:
>>
>> $ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
>> 0: ./subversion/svn/svn
>> 1: ls
>> 2: svn://localhost/kde
>> 3: --search
>> 4: M*
> Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
> would expand the asterisk. While this is not the default shell behavior,
> currently it's enabled for svn and a couple of other binaries by linking
> to setargv.obj.
We do that for the command-line client and in a few other places, too.
It was the easy way out for Windows.
It's unfortunate, really ... ideally, we'd remove setargv.obj and do the
wildcard expansion ourselves, but someone has to do the work; it's very
Windows-specific and there are probably nasty edge cases around argument
quoting.
-- Brane
Re: Subversion 1.10 RC1?
Posted by Johan Corveleyn <jc...@gmail.com>.
Op 5 dec. 2017 22:13 schreef "Evgeny Kotkov" <ev...@visualsvn.com>:
Stefan Fuhrmann <st...@apache.org> writes:
> There seems to be little that could be done here (suggestions welcome).
> The problem is that the asterisk is being expanded by the shell itself.
> I made SVN print its command line parameters and this is the result:
>
> $ ./subversion/svn/svn ls svn://localhost/kde --search M*
> 0: ./subversion/svn/svn
> 1: ls
> 2: svn://localhost/kde
> 3: --search
> 4: Makefile
> 5: Makefile.in
>
> That can be prevented by adding quotation marks:
>
> $ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
> 0: ./subversion/svn/svn
> 1: ls
> 2: svn://localhost/kde
> 3: --search
> 4: M*
Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
would expand the asterisk. While this is not the default shell behavior,
currently it's enabled for svn and a couple of other binaries by linking
to setargv.obj. In turn, this probably means the command-line client
users on Windows could get quite unexpected results when using the
`--search ARG` syntax.
A potential cheap solution for this issue, I think, would be to make the
--search argument work as a substring to search for in filenames, instead
of using it as a pattern that the (whole) filename should match. While
there are some cases where the latter approach gives more flexibility,
my guess would be that a substring search would work well in the majority
of scenarios.
(Also, as far as I recall, `log --search` currently searches for a
substring,
so that would be consistent with it, and would probably avoid surprising
the users by having a switch with the same name, but behaving differently.)
Thanks,
Evgeny Kotkov
(Sorry if quoting is broken above ... I blame Google)
We've discussed whether ls --search should always match substrings or exact
before, and the people participating in that thread were in favor of exact
matching:
https://svn.haxx.se/dev/archive-2017-09/0002.shtml
Consistency with log --search also came up, but wasn't a good argument for
most.
Of course, if this would be the only way to make this work on Windows, some
people might reconsider ...
--
Johan
Re: Subversion 1.10 RC1?
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Stefan Fuhrmann <st...@apache.org> writes:
> There seems to be little that could be done here (suggestions welcome).
> The problem is that the asterisk is being expanded by the shell itself.
> I made SVN print its command line parameters and this is the result:
>
> $ ./subversion/svn/svn ls svn://localhost/kde --search M*
> 0: ./subversion/svn/svn
> 1: ls
> 2: svn://localhost/kde
> 3: --search
> 4: Makefile
> 5: Makefile.in
>
> That can be prevented by adding quotation marks:
>
> $ ./subversion/svn/svn ls svn://localhost/kde --search "M*"
> 0: ./subversion/svn/svn
> 1: ls
> 2: svn://localhost/kde
> 3: --search
> 4: M*
Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
would expand the asterisk. While this is not the default shell behavior,
currently it's enabled for svn and a couple of other binaries by linking
to setargv.obj. In turn, this probably means the command-line client
users on Windows could get quite unexpected results when using the
`--search ARG` syntax.
A potential cheap solution for this issue, I think, would be to make the
--search argument work as a substring to search for in filenames, instead
of using it as a pattern that the (whole) filename should match. While
there are some cases where the latter approach gives more flexibility,
my guess would be that a substring search would work well in the majority
of scenarios.
(Also, as far as I recall, `log --search` currently searches for a substring,
so that would be consistent with it, and would probably avoid surprising
the users by having a switch with the same name, but behaving differently.)
Thanks,
Evgeny Kotkov