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

Re: svn commit: r1383480 - in /subversion/trunk/subversion: svn/cl.h svn/log-cmd.c svn/main.c tests/cmdline/getopt_tests_data/svn_help_log_switch_stdout tests/cmdline/log_tests.py

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 21 Sep 2012 13:34:57 +0200

On 21.09.2012 11:28, Stefan Sperling wrote:
> On Fri, Sep 21, 2012 at 11:10:57AM +0200, Branko Čibej wrote:
>> Is doing this in the log receiver really any faster than filtering in a
>> custom callback handler, or even a script?
> It's not. And it is not about the speed of the filtering itself.
> 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; alternatively, the query language could have a CI operator
that made the associated subquery case-insensitive (and the obverse CS
operator).

Here's a quick stab at a BNF:

term :== atom | '"' atom... '"';
expr :== term | prefix-expr | infox-expr | paren-expres;
prefix-expr :== NOT expr | CI expr | CS expr;
infix-expr :== expr AND expr | expr OR expr;
paren-expr :== '(' expr ')';
atom :== /[^ ()]*/;

This shouldn't be any harder to write than the skel parser; and there
might already be ALv2-licensed code available that does something similar.

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.

-- Brane

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-09-21 13:35:42 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.