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

Log search UI options [was: svn commit: r1383480 ...]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 21 Sep 2012 13:07:24 +0100 (BST)

I changed the subject line.  And...

Branko Čibej wrote:

> On 21.09.2012 11:28, Stefan Sperling wrote:
>> It is much more convenient to have this built in, especially on
>> platforms that don't have nice post-processing tools installed
>> by default (e.g. Windows).
>
> OK.
>
>> I've been using it several times already to find commit messages
>> for things that I only vaguely remembered -- e.g. "when did stefan2
>> fix this bug where we worked around APR file flush being broken?".
>>
>> The command "svn log --search stefan2 --search-and flush" returns
>> just two log messages (r1325899 and r1240752) to pick from.
>> For me, as a human who is bad at scanning large amounts of pages
>> in a pager even with assistance from the pager's built-in search,
>> that speeds things up. It works well for that kind of thing.
>
> Cool. So we're back to UI design. :)
>
> Caveat lector: I'm not volunteering to implement what I'm about to
> propose.
>
> How about having just the --search option and creating a simple query
> language parser using parenthesis, AND, NOT and OR operators? I'd even
> consider making such searching always case-insensitive, at least for log
> messages;

One idea stands out as an immediate improvement: have the basic, simple, generic search commands be case-insensitive.  Instead of the present

  --search
  --isearch (or was it --i-search? no, just playing mind games),
  --search-and
  --isearch-and

reduce the current implementation to just

  --search
  --search-and

and make those case-insensitive.  Always.

The point is, if the aim is to provide a simple-to-use search that "just works" for typical human needs, I think just being case-insensitive will achieve this better.

[...]
> My point is that, if we want to add regular expression support at a
> later time, we can invent a "regex" production that'll fit into
> the
> query syntax, instead of doubling the number of options for each command
> that supports searching.

Yes, that argument is a good one, as long as we don't make the expression syntax too arcane.

- Julian
Received on 2012-09-21 14:21:11 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.