[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn ls --search/pattern/glob/case-insensitive

From: Stefan Fuhrmann <stefan2_at_apache.org>
Date: Sat, 2 Sep 2017 18:47:16 +0200

On 01.09.2017 17:24, Julian Foad wrote:
> Stefan Sperling wrote:
>> On Fri, Sep 01, 2017 at 03:01:33PM +0100, Julian Foad wrote:

>> The above behaviour looks good to me.
>>
>> However, as you already pointed out, matching child path components
>> seems to be impossible at present:
>>
>> $ svn ls -r3 --pattern 'trunk/*'
>> $
>> $ svn ls -R -r3 --pattern 'trunk/*' ^/
>> $
>>
>> These should print:
>>
>> trunk/dog.txt
>> trunk/lazy_dog.txt
>>
>> There is of course an interaction with --depth to consider.
>> This already works:
>>
>> $ svn ls -R -r3 --pattern '*dog*' ^/
>> trunk/dog.txt
>> trunk/lazy_dog.txt
>> $ svn ls -R -r3 --pattern '*trunk*' ^/
>> trunk/
>> $
>>
>> Which suggests that matching happens after depth filtering.
>> Perhaps a default depth should be chosen based on the pattern to allow
>> patterns such as 'trunk/*' to match?
>>
>> Regarding case:
>>
>> If 'list --search' is designed to be case-insensitive, then this:
>>
>> $ svn ls -r3 --pattern 'Dog*' ^/trunk
>> $
>>
>> should print:
>>
>> dog.txt
> [...]
>
> All of the above looks good to me, apart from maybe we haven't nailed
> the details of how paths starting with "^/" or "/" are matched.

I've been thinking about matching whole paths instead of
just the (latest) segment. But it seems to either make
the pattern spec needlessly complicated, difficult to
predict or too loose:

* Finding all "readme"s:
   "*/readme*" instead of"readme*"

* Implicit "*/" prefixes might be added, but only of the
   pattern does not start with a "/":
   "foo" -> "*/foo"
   "foo/bar" -> "*/foo/bar"
   "*/foo" -> "*/foo" (unchanged)

* Which one of the following should match "foo/bar"?
   "foo/*/bar", "foo*/bar", "foo*bar"

* Which one of the following should match everything in
   the whole sub-tree "/foo", which would not include "/foo"
   itself?
   "foo/*", "foo/", "foo*"

I guess we could come up with a solution for all of these
and the implementation will most likely not be too hard.
But it all seems convoluted for typical use-cases like
"Where the heck is file xyz?", "Did somebody create a
branch folder inside trunk?" or "How many Python files
are there?"

-- Stefan^2.
Received on 2017-09-02 18:47:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.