On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff <veedeeh...@googlemail.com>wrote:
> On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp <d...@sqlite.org> wrote:
>
> On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell <vi...@viric.name
>> >wrote:
>>
>> On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hipp wrote:
>>> > On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff <
>>> veedeeh...@googlemail.com>**wrote:
>>> >
>>> > > question: is there a straightforward (or sqlite-based) way to `grep'
>>> > > through a specified file recursively backward in time through all
>>> revisions
>>> > > (or until first hit of the search pattern)?
>>> > >
>>> > > j.
>>> > >
>>> > > ps: yes, I would know now (after having learned how to use `fossil
>>> > > artifact' correctly...) how to write a shell script doing that. but
>>> that
>>> > > would mean to dump the full content of each revision and pipe it
>>> through
>>> > > the grep which will become slow if there are too many revisions. so
>>> the
>>> > > question is whether the functionality is already builtin (possibly
>>> grepping
>>> > > through the deltas instead).
>>> > >
>>> >
>>> > This functionality is not built-in. Nobody has ever thought of it
>>> before
>>> > in 6 years of use, apparently, or at least has not mentioned it to me.
>>>
>>> I use this from time to time. My procedure goes through deconstructing
>>> the
>>> database, grepping recursive, and resolving back the hashes with fossil
>>> ui.
>>>
>>>
>> So what should the output look like? Suppose we implement a command:
>>
>> fossil grep REGEXP FILENAMEGLOB
>>
>> Which searches all historical versions of files that match FILENAMEGLOB
>> for
>> patterns that match REGEXP. Suppose for concreteness that the regular
>> expression is "xyzzy" and the file is "ex1.txt". If there are 1000
>> different revisions of ex1.txt, does it search them all looking for
>> "xyzzy"
>> and show each hit? Or did it stop going backwards in time at the first
>> hit
>> it find?
>>
>
> should stop at first hit by default but allow going through complete
> history optionally.
> I feel the `hg' people did it essentially right regarding this question:
>
> 8<----------------------------**---------------------------
> hg grep [OPTION]... PATTERN [FILE]...
>
> search for a pattern in specified files and revisions
>
> Search revisions of files for a regular expression.
>
> This command behaves differently than Unix grep. It only accepts
> Python/Perl regexps. It searches repository history, not the working
> directory. It always prints the revision number in which a match
> appears.
>
> By default, grep only prints output for the first revision of a file in
> which it finds a match. To get it to print every revision that
> contains a
> change in match status ("-" for a match that becomes a non-match, or
> "+"
> for a non-match that becomes a match), use the --all flag.
>
> Returns 0 if a match is found, 1 otherwise.
>
> options:
>
> -0 --print0 end fields with NUL
> --all print all revisions that match
> -a --text treat all files as text
> -f --follow follow changeset history, or file history across
> copies and renames
> -i --ignore-case ignore case when matching
> -l --files-with-matches print only filenames and revisions that match
> -n --line-number print matching line numbers
> -r --rev REV [+] only search files changed within revision range
> -u --user list the author (long with -v)
> -d --date list the date (short with -q)
> -I --include PATTERN [+] include names matching the given patterns
> -X --exclude PATTERN [+] exclude names matching the given patterns
> --mq operate on patch repository
>
> [+] marked option can be specified multiple times
> 8<----------------------------**---------------------------
>
> this of course is already quite elaborate and thus not a proposal to do
> the same...
>
> but the default behaviour (stop at first hit) is good, the flags `l', `r'
> important, `u', `d', `i' sensible in my view.
>
One big problem here is that the user will doubtless expect to have full
Perl regular expressions. That will mean another compile-time dependency.
And maybe also a run-time dependency if a shared library is used (as most
distribution packages managers will likely require). Suddenly, Fossil
becomes much less stand-alone and self-contained.
When I get around to working on this, perhaps I'll compromise and use a
simpler Posix Extended Regular Expression library that can be compiled in,
and thus avoid the extra dependencies.
>
> j.
>
>
>
>
>>
>>
>>
>>> Regards,
>>> Lluís.
>>> ______________________________**_________________
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.**org <fossil-users@lists.fossil-scm.org>
>>> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**
>>> fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
>>>
>>>
>>
>>
>>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
