On Sat, 24 Nov 2012 15:21:54 +0100, Richard Hipp <d...@sqlite.org> wrote:
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.
no, no, heaven forbid. I didn't mean that. I have in mind more modest
functionality.
for me, at least, I would nearly be happy with fixed string patterns and
glob patterns like
"something*other" (or the regex equivalent "something.*other")
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.
definitely no good. I'm a strong believer in "small and self-contained is
beautiful".
that is, what I find really appealing in `fossil'.
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.
yes, definitely preferable in my view. maybe there are even smaller and
(for this purpose sufficient) pattern-matching
libraries? even shell glob patterns might do (or what `lua' is using
instead of regex at 1/10 LOC or so).
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/
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
