Stefan Sperling wrote: > On Fri, Sep 01, 2017 at 03:01:33PM +0100, Julian Foad wrote: >> (I'm unsure exactly what you meant there, stsp -- that seems to >> contradict the previous paragraph, if 'svn log --search remains >> case-insensitive.) > > The most important point for me is that I don't think appending and > prepending * globs is useful in the context of a path search with 'ls'.
Agreed. > Consider a revision such as: > > $ svn log -r 3 -v > ------------------------------------------------------------------------ > r3 | stsp | 2017-09-01 16:12:23 +0200 (Fri, 01 Sep 2017) | 1 line > Changed paths: > A /trunk/dog.txt > A /trunk/lazy_dog.txt > > the quick brown fox jumps over the lazy dog > ------------------------------------------------------------------------ > > The behaviour for log --search is that either '--search lazy' or > '--search dog' will match this revision. This is fine because we are > looking for log message output rather than path names. > > $ svn log --search dog > ------------------------------------------------------------------------ > r3 | stsp | 2017-09-01 16:12:23 +0200 (Fri, 01 Sep 2017) | 1 line > > the quick brown fox jumps over the lazy dog > ------------------------------------------------------------------------ > $ svn log --search lazy > ------------------------------------------------------------------------ > r3 | stsp | 2017-09-01 16:12:23 +0200 (Fri, 01 Sep 2017) | 1 line > > the quick brown fox jumps over the lazy dog > ------------------------------------------------------------------------ I agree this is fine when we are talking about searching in the *log message*. But when I talk about consistency between "list" and "log", I'm thinking of the searching in *paths*, which should (and does) work like this: $ svn log -vq --search quick $ # no results $ svn log -vq --search dog Changed paths: A /trunk/dog.txt A /trunk/lazy_dog.txt > However, when matching paths with 'svn ls' I would not expect 'dog*' to > match lazy_dog.txt. The output is a list of paths, not a log message. > I would expect matching to behave more like a unix shell does with ls(1). Agreed. And, for consistency, when matching paths with "svn log -vq --search..." I would expect the same (I would not expect 'dog*' to match lazy_dog.txt). At present the implementation does match it, because it treats the pattern as a substring both when searching in the log message and also when searching in the paths. I propose that one way to get consistency is if we change "svn log --search" so it treats the pattern as a substring in the log message but not in the paths. > The current behaviour as implemented by --pattern looks like: > > $ svn ls -r3 --pattern 'dog*' ^/ > $ svn ls -r3 --pattern 'dog*' ^/trunk > dog.txt > $ svn ls -r3 --pattern '*dog*' ^/trunk > dog.txt > lazy_dog.txt > > 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. - Julian