Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 5:37 PM, Richard Hipp d...@sqlite.org wrote: I haven't yet figure out the right syntax for doing a grep of files in the repository. The implementation should be relatively easy once the right interface is designed. Suggestions are welcomed. My 2 cents: fossil grep [--type [w][ci][tk][tm]] [--from VERSION] [--to VERSION] [--branch BRANCH] [--first|--last|--change] [FILE_GLOB ...] SEARCH_PATTERN Explanation: type - what type of artifacts to search (e.g. wcitk = wiki, file, tickets) default: ci from/to - limit the search to artifacts from this range (dates, checkins, etc.) default: only the currently checked out version (but the clean one, not the dirty state) branch - only search this branch/tag first - only show the earliest match last - only show the latest match (default) change - show every commit that changed this (either added or removed it) Not sure the --change option is possible. Also, I only use fossil for regular source control, not wiki/ticket stuff, and I have never needed the grep option, so I am just suggesting what I think may make sense, but someone who uses all this may say that this type of searching doesn't make sense to some types of content. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Tue, Jan 29, 2013 at 08:59:19AM +0100, Gilles wrote: On Tue, 29 Jan 2013 00:10:26 -0700, Matt Welland estifo...@gmail.com wrote: Sorry, didn't paste in the second grep: Thanks for contributing this work-around. I guess it shows that there's a need for an easy, integrated grep to find code in the repository. Well, at least for me, it's very important to be able to grep wiki pages and specially tickets too. I think 'export' won't work, right? Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Tue, 29 Jan 2013 09:17:11 +0100, Lluís Batlle i Rossell vi...@viric.name wrote: Well, at least for me, it's very important to be able to grep wiki pages and specially tickets too. I think 'export' won't work, right? Right. Grep should be able to scan any item in the repo, not just code. I just happen not to use its wiki and ticket features yet. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp d...@sqlite.org wrote: On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote: Since this thread is a bit long, I'd like to ask: At this point, what is the solution to find a piece of code that can be in any revision in any file in the repository? As I said early in the thread, deconstruct + grep. :) What do you mean by deconstruct? Checking files out? On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp d...@sqlite.org wrote: (1) grep function_name *.c */*.c# Adjust GLOB expressions as appropriate (2) fossil up prev (3) goto (1) Repeat until the grep finds your function. Is there a way to just check files out into RAM before calling grep so that the files aren't written to disk, which would speed things up? Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 10:21:03AM +0100, Gilles wrote: On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp d...@sqlite.org wrote: On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote: Since this thread is a bit long, I'd like to ask: At this point, what is the solution to find a piece of code that can be in any revision in any file in the repository? As I said early in the thread, deconstruct + grep. :) What do you mean by deconstruct? Checking files out? As this question goes to me... $ fossil help deconstruct ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 10:43:19 +0100, Lluís Batlle i Rossell vi...@viric.name wrote: What do you mean by deconstruct? Checking files out? As this question goes to me... $ fossil help deconstruct Thanks. After running deconstruct, do you just grep through all the files, regardless of whether they contain actual code or just the output from artifact? Is there a way to avoid writing all those files to disk, and just output data to STDOUT and read this with grep? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 11:01:32AM +0100, Gilles wrote: On Mon, 28 Jan 2013 10:43:19 +0100, Lluís Batlle i Rossell vi...@viric.name wrote: What do you mean by deconstruct? Checking files out? As this question goes to me... $ fossil help deconstruct Thanks. After running deconstruct, do you just grep through all the files, regardless of whether they contain actual code or just the output from artifact? Grep all files Is there a way to avoid writing all those files to disk, and just output data to STDOUT and read this with grep? I don't know how to do that. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 3:21 PM, Richard Hipp d...@sqlite.org wrote: 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. i know this topic is a bit dated now, but this might be of interest: https://code.google.com/p/lua-regex-standalone/ a small, standalone implementation of regexes ported out of the LUA sources. Has a MIT license. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 6:15 AM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Nov 24, 2012 at 3:21 PM, Richard Hipp d...@sqlite.org wrote: 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. i know this topic is a bit dated now, but this might be of interest: https://code.google.com/p/lua-regex-standalone/ a small, standalone implementation of regexes ported out of the LUA sources. Has a MIT license. Fossil already has http://www.fossil-scm.org/fossil/artifact/c8fb75a1615f?ln=21-23 and the test-grep command. I didn't know about the LUA regexp library - I will investigate it though. I was -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 12:15:22 +0100, Stephan Beal sgb...@googlemail.com wrote: On Sat, Nov 24, 2012 at 3:21 PM, Richard Hipp d...@sqlite.org wrote: 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. i know this topic is a bit dated now, but this might be of interest: https://code.google.com/p/lua-regex-standalone/ a small, standalone implementation of regexes ported out of the LUA sources. Has a MIT license. I'm quite sure that this is _not_ a standard regexp lib, but rather lua's own (and somewhat different) substitute, called lua patterns, I believe. the lua authors used to make a point of the fact, that the whole lua implementation is smaller (in terms of LOC) than the usual regexp libs... the syntax for lua patterns is somewhat different from regexp syntax (but quite nice/reasonable: eg. one or more white space chars would be %s+, %w is an alphanumeric char, etc.. there are also captures (backreferences to matched subpatterns), so capabilities are good, sometimes maybe superior to standard regexp). the one thing which used to be missing (and quite probably still is) is logical alterations (OR combination within patterns, such as (apple|banana)). this is only to clarify the situation. otherwise I fully support this proposal (since the lua patterns implementation is quite powerful and also very light, much lighter than perl or standard regexp). j. -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 7:24 AM, j. van den hoff veedeeh...@googlemail.comwrote: On Mon, 28 Jan 2013 12:15:22 +0100, Stephan Beal sgb...@googlemail.com wrote: I'm quite sure that this is _not_ a standard regexp lib, but rather lua's own (and somewhat different) substitute, called lua patterns, I believe. the lua authors used to make a point of the fact, that the whole lua implementation is smaller (in terms of LOC) than the usual regexp libs... the syntax for lua patterns is somewhat different from regexp syntax (but quite nice/reasonable: eg. one or more white space chars would be %s+, %w is an alphanumeric char, etc.. there are also captures (backreferences to matched subpatterns), so capabilities are good, sometimes maybe superior to standard regexp). the one thing which used to be missing (and quite probably still is) is logical alterations (OR combination within patterns, such as (apple|banana)). Indeed - I don't find '|' anywhere in the source code, so I think this capability is missing. I've only glanced at the lua-regexp.c, but it appears to be a direct matching of the regexp string against the input string, using backtracking. In this sense, it is similar to the GLOB operator implemented at http://www.fossil-scm.org/fossil/artifact/3d47a43dc9a?ln=155-217 but with a lot of additional logic to deal with substitutions and the expanded functionality of regular expressions. This is a clever design. All other regexp engines that I've seen (including the one in www.fossil-scm.org/fossil/artifact/c8fb75a1615f) compile the regexp into a state machine first, then run the state machine over the input string. Possible this is why the lua-regexp engine does not handle '|' - because doing so is difficult without a certain amount of preprocessing of the regular expression text. this is only to clarify the situation. otherwise I fully support this proposal (since the lua patterns implementation is quite powerful and also very light, much lighter than perl or standard regexp). The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 07:15:13 -0500, Richard Hipp d...@sqlite.org wrote: Fossil already has http://www.fossil-scm.org/fossil/artifact/c8fb75a1615f?ln=21-23 and the test-grep command. test-grep doesn't show up with fossil help * in my 1.24. Was it added recently and not yet available in the Windows binary? I guess that won't be necessary if grep is coming to Fossil soon, but as a temporary work-around, I was looking at using a RAM disk to dump the output of fossil deconstruct. The freeware version of DataRam RAM (http://memory.dataram.com/products-and-services/software/ramdisk) supports disk sizes up to 4 GB. Is there a command to know in advance the total size of the output from fossil deconstruct? If not, will it just stop extracting files if it exceeds 4GB? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 15:25:19 +0100 Gilles gilles.gana...@free.fr wrote: On Mon, 28 Jan 2013 11:22:11 +0100, Lluís Batlle i Rossell vi...@viric.name wrote: Is there a way to avoid writing all those files to disk, and just output data to STDOUT and read this with grep? I don't know how to do that. Thanks. I'll see if there's a way to create some kind of temporary disk in RAM. If you use FreeBSD, this is what i have in my central repository server: In /etc/fstab: md /mnt/fossiltmp mfs rw,-M-S32m 2 0 # 32 MB memory disk I use intensively this because in each sync i, or someone, make to my central repository server this script runs: #!/bin/sh cd /mnt/fossiltemp fossil open $1 makeheaders -f makeheaders.dat scan-build -o/mnt/fossiltemp/stats/ -vv make fossil addremove fossil commit -m $(date) fossil close rm -rf /mnt/fossiltmp/* This way i create the html pages from clang/llvm statical analyzer and commit them to the project when some one . It's fast, i can live without 32MB of ram on this server but not clean, because a new commit is done each sync. You can use a similar approach for your grep problem and if you are trying to find when you add something use fossil bisect --- --- Eduardo Morras emorr...@yahoo.es ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 10:27 AM, Gilles gilles.gana...@free.fr wrote: On Mon, 28 Jan 2013 07:15:13 -0500, Richard Hipp d...@sqlite.org wrote: Fossil already has http://www.fossil-scm.org/fossil/artifact/c8fb75a1615f?ln=21-23 and the test-grep command. test-grep doesn't show up with fossil help * in my 1.24. Was it added recently and not yet available in the Windows binary? test-grep is recent. And so far, test-grep does not do what you are wanting it to do. test-grep is just a test platform for the regexp engine. I haven't yet figure out the right syntax for doing a grep of files in the repository. The implementation should be relatively easy once the right interface is designed. Suggestions are welcomed. I guess that won't be necessary if grep is coming to Fossil soon, but as a temporary work-around, I was looking at using a RAM disk to dump the output of fossil deconstruct. The freeware version of DataRam RAM (http://memory.dataram.com/products-and-services/software/ramdisk) supports disk sizes up to 4 GB. Is there a command to know in advance the total size of the output from fossil deconstruct? If not, will it just stop extracting files if it exceeds 4GB? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote: The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. The Lua implementation starts to perform very badly as soon as you have wild cards at the beginning of the pattern. Those aren't even obscure... Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote: The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. The Lua implementation starts to perform very badly as soon as you have wild cards at the beginning of the pattern. Those aren't even obscure... just a guess: you did not anchor the pattern, i.e. you used something like .*foo instead of ^.*foo? I seem to recall that this is always a problem (not only with lua) since it forces way to many checks for potential matches (because short substrings in the middle of the line also match .* and all possibilities are tested separately). IIRC, anchoring the pattern solves the problem of excessive run time for such patterns. but maybe my memory fails me and this is wrong ... j. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote: On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote: The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. The Lua implementation starts to perform very badly as soon as you have wild cards at the beginning of the pattern. Those aren't even obscure... just a guess: you did not anchor the pattern, i.e. you used something like .*foo instead of ^.*foo? Anchoring doesn't help if you want to explicitly match wild card chars at or near the beginning. With a NFA or DFA based implementation, it will add some processing time, but the linear performance is still guaranteed. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote: On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote: The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. The Lua implementation starts to perform very badly as soon as you have wild cards at the beginning of the pattern. Those aren't even obscure... just a guess: you did not anchor the pattern, i.e. you used something like .*foo instead of ^.*foo? Anchoring doesn't help if you want to explicitly match wild card chars at or near the beginning. With a NFA or DFA based implementation, it I'm too slow: could you give an example where anchoring would come in the way of what you really want to match? j. will add some processing time, but the linear performance is still guaranteed. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
2013/1/28 Richard Hipp d...@sqlite.org I haven't yet figure out the right syntax for doing a grep of files in the repository. The implementation should be relatively easy once the right interface is designed. Suggestions are welcomed. I think there are three use cases: (1) searching timeline, (2) searching current code, (3) searching code history. (1) can be done now by fossil timeline | grep ... but having it integrated would be much easier to work with (and also available to Windows users). I'd suggest simply adding a parameter with a regexp, which would filter only those timeline items that match it. For (2) and (3) we can lear how git grep does it and also what are its shortcomings. I found this q/a: How to grep (search) committed code in the git history? http://stackoverflow.com/q/2928584/1333025 It seems that while (3) is easy with git, it requires some shell features that could be problematic on Windows. What about this: fossil grep regex [path..] would grep current working tree, optionally limited to the given path. And fossil grep --some-param regex1 regex [path...] would grep with regex those historical versions whose commit message or hash matches regex1. This way, we could flexibly search specific hashes, look for a certain feature, or grep everything with fossil grep --some-param regex [Note that (2) can be done now by something like fossil ls|xargs grep ... on Linux systems.] Best regards, Petr Pudlak ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 1:30 PM, Petr P petr@gmail.com wrote: 2013/1/28 Richard Hipp d...@sqlite.org I haven't yet figure out the right syntax for doing a grep of files in the repository. The implementation should be relatively easy once the right interface is designed. Suggestions are welcomed. I think there are three use cases: (1) searching timeline, (2) searching current code, (3) searching code history. Good analysis. But perhaps more is needed. I think hg, for example, provides (4) the ability to grep back through the history of a file looking for the most recent version that matches (or does not match) some regexp. (1) can be done now by fossil timeline | grep ... but having it integrated would be much easier to work with (and also available to Windows users). I'd suggest simply adding a parameter with a regexp, which would filter only those timeline items that match it. For (2) and (3) we can lear how git grep does it and also what are its shortcomings. I found this q/a: How to grep (search) committed code in the git history? http://stackoverflow.com/q/2928584/1333025 It seems that while (3) is easy with git, it requires some shell features that could be problematic on Windows. What about this: fossil grep regex [path..] would grep current working tree, optionally limited to the given path. And fossil grep --some-param regex1 regex [path...] would grep with regex those historical versions whose commit message or hash matches regex1. This way, we could flexibly search specific hashes, look for a certain feature, or grep everything with fossil grep --some-param regex [Note that (2) can be done now by something like fossil ls|xargs grep ... on Linux systems.] Best regards, Petr Pudlak ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 07:26:32PM +0100, j. v. d. hoff wrote: On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote: On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote: The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. The Lua implementation starts to perform very badly as soon as you have wild cards at the beginning of the pattern. Those aren't even obscure... just a guess: you did not anchor the pattern, i.e. you used something like .*foo instead of ^.*foo? Anchoring doesn't help if you want to explicitly match wild card chars at or near the beginning. With a NFA or DFA based implementation, it I'm too slow: could you give an example where anchoring would come in the way of what you really want to match? You don't understand me. Anchoring helps, if you can use it to avoid initial wild cards or limit the length of backtracking. It doesn't help to avoid the exponential edge cases with .*foo patterns though. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 1:40 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: You don't understand me. Anchoring helps, if you can use it to avoid initial wild cards or limit the length of backtracking. It doesn't help to avoid the exponential edge cases with .*foo patterns though. I think another point is that the Lua regexp does not do anchoring (or at least I didn't see it - did I miss something?) FWIW, the regexp.c code already present in Fossil does not need anchoring to avoid exponential blowup, since it uses an NFA. However, it does use anchoring as a performance optimization, to avoid running the NFA over every byte of input text. The NFA is linear in the size of input, but the constant of proportionality is large relative to memcmp() so we like to use memcmp()-based anchoring to avoid having the NFA look at every single byte of input. -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 19:46:13 +0100, Richard Hipp d...@sqlite.org wrote: On Mon, Jan 28, 2013 at 1:40 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: You don't understand me. Anchoring helps, if you can use it to avoid initial wild cards or limit the length of backtracking. It doesn't help to avoid the exponential edge cases with .*foo patterns though. I think another point is that the Lua regexp does not do anchoring (or at least I didn't see it - did I miss something?) you mean in the pattern syntax? then see, e.g., here: http://www.lua.org/pil/20.2.html and search for anchor: lua uses the same syntax as standard regexp for this, e.g. ^.*foo means search for anything at beginning of line followed by foo FWIW, the regexp.c code already present in Fossil does not need anchoring to avoid exponential blowup, since it uses an NFA. However, it does use anchoring as a performance optimization, to avoid running the NFA over every byte of input text. The NFA is linear in the size of input, but the constant of proportionality is large relative to memcmp() so we like to use memcmp()-based anchoring to avoid having the NFA look at every single byte of input. -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 19:40:17 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 07:26:32PM +0100, j. v. d. hoff wrote: On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote: On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote: The regular expression matching in www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it supports | and it is usually as fast or faster than grep in my tests (though there are some cases for which grep is faster). The regexp.c in fossil uses a NFA which gives worst case performance of O(NM) where N is the size of the input text to be matched and M is the size of the regular expression. Perl regular expressions and lua-regexp.c take exponential time for some (admittedly obscure) regular expressions. On the other hand, Perl regular expressions are more complete, and both Lua and Perl allow you to do substitutions, which the regexp.c file in Fossil does not. The Lua implementation starts to perform very badly as soon as you have wild cards at the beginning of the pattern. Those aren't even obscure... just a guess: you did not anchor the pattern, i.e. you used something like .*foo instead of ^.*foo? Anchoring doesn't help if you want to explicitly match wild card chars at or near the beginning. With a NFA or DFA based implementation, it I'm too slow: could you give an example where anchoring would come in the way of what you really want to match? You don't understand me. Anchoring helps, if you can use it to avoid right. as I said: I'm too slow. initial wild cards or limit the length of backtracking. It doesn't help to avoid the exponential edge cases with .*foo patterns though. I understand/know that .*foo will take (too) much time. my point/question is/was: ^.*foo seemingly matches everything which is matched by .*foo. (and if matching is greedy (is that the term?), than .*foo would also return exactly the same matching string as ^.*foo, making the two actually equivalent patterns, if I understand correctly). but in any case if the question is simply match or no match? (we are not talking about capturing subexpressions and doing substitutions but grepping functionality for fossil, right?), the anchored pattern could always serve as a dropin replacement of .*foo, AFAICS (even if the reverse where not true). this would not prevent, that people run into the exponential run time problem when using the naive pattern instead the anchored one, but this could be explained by a FAQ entry making the problem practically irrelevant. or do I still miss the relevant point? j. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, 28 Jan 2013 19:46:13 +0100, Richard Hipp d...@sqlite.org wrote: I think another point is that the Lua regexp does not do anchoring (or at least I didn't see it - did I miss something?) see also here (from http://www.lua.org/pil/20.4.html): Usually, pattern matching is efficient enough for Lua programs: A Pentium 333MHz (which is not a fast machine by today's standards) takes less than a tenth of a second to match all words in a text with 200K characters (30K words). But you can take precautions. You should always make the pattern as specific as possible; loose patterns are slower than specific ones. An extreme example is '(.-)%$', to get all text in a string up to the first dollar sign. If the subject string has a dollar sign, everything goes fine; but suppose that the string does not contain any dollar signs. The algorithm will first try to match the pattern starting at the first position of the string. It will go through all the string, looking for a dollar. When the string ends, the pattern fails for the first position of the string. Then, the algorithm will do the whole search again, starting at the second position of the string, only to discover that the pattern does not match there, too; and so on. This will take a quadratic time, which results in more than three hours in a Pentium 333MHz for a string with 200K characters. You can correct this problem simply by anchoring the pattern at the first position of the string, with '^(.-)%$'. The anchor tells the algorithm to stop the search if it cannot find a match at the first position. With the anchor, the pattern runs in less than a tenth of a second. Beware also of empty patterns, that is, patterns that match the empty string. For instance, if you try to match names with a pattern like '%a*', you will find names everywhere: i, j = string.find(;$% **#$hello13, %a*) print(i,j) -- 1 0 In this example, the call to string.find has correctly found an empty sequence of letters at the beginning of the string. It never makes sense to write a pattern that begins or ends with the modifier `-´, because it will match only the empty string. This modifier always needs something around it, to anchor its expansion. Similarly, a pattern that includes '.*' is tricky, because this construction can expand much more than you intended. -- 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
Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote: this would not prevent, that people run into the exponential run time problem when using the naive pattern instead the anchored one, but this could be explained by a FAQ entry making the problem practically irrelevant. or do I still miss the relevant point? The very existence of naive patterns is the point. It is kind of a FAQ with the canonical answer being http://swtch.com/~rsc/regexp/regexp1.html. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
I haven't read all of the messages in this thread so please pardon the top post and possible useless or redundant info but my lazy and oh so very wrong method of grepping an entire fossil repo is to use fossil export and some grepping. No need to put the whole expanded repo on disk. First find the mark record. I was looking for some code where I started using a transaction: $ fsl export |egrep '^data\s+[0-9]\s*$|^blob|^mark\s+:[0-9]+$|transaction'|less mark :1904 blob mark :1906 (with-transaction blob Then use grep to find the comment and check in info, in my case it was in tasks.scm around Oct 23 (just convert seconds to time): commit refs/heads/trunk mark :1909 committer matt matt 1319432626 + data 31 Monitor based runs working well from :1895 M 100644 :1896 Makefile M 100644 :1898 db.scm M 100644 :1900 runs.scm M 100644 :1906 tasks.scm M 100644 :1902 tests/Makefile M 100644 :1904 tests/megatest.config commit refs/heads/trunk mark :1915 committer matt matt 1319449002 + data 43 Added missing dashboard-guimonitor.scm file from :1909 On Mon, Jan 28, 2013 at 1:06 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote: this would not prevent, that people run into the exponential run time problem when using the naive pattern instead the anchored one, but this could be explained by a FAQ entry making the problem practically irrelevant. or do I still miss the relevant point? The very existence of naive patterns is the point. It is kind of a FAQ with the canonical answer being http://swtch.com/~rsc/regexp/regexp1.html. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
Sorry, didn't paste in the second grep: fsl export | grep -A 10 -B 10 :1906 On Tue, Jan 29, 2013 at 12:08 AM, Matt Welland estifo...@gmail.com wrote: I haven't read all of the messages in this thread so please pardon the top post and possible useless or redundant info but my lazy and oh so very wrong method of grepping an entire fossil repo is to use fossil export and some grepping. No need to put the whole expanded repo on disk. First find the mark record. I was looking for some code where I started using a transaction: $ fsl export |egrep '^data\s+[0-9]\s*$|^blob|^mark\s+:[0-9]+$|transaction'|less mark :1904 blob mark :1906 (with-transaction blob Then use grep to find the comment and check in info, in my case it was in tasks.scm around Oct 23 (just convert seconds to time): commit refs/heads/trunk mark :1909 committer matt matt 1319432626 + data 31 Monitor based runs working well from :1895 M 100644 :1896 Makefile M 100644 :1898 db.scm M 100644 :1900 runs.scm M 100644 :1906 tasks.scm M 100644 :1902 tests/Makefile M 100644 :1904 tests/megatest.config commit refs/heads/trunk mark :1915 committer matt matt 1319449002 + data 43 Added missing dashboard-guimonitor.scm file from :1909 On Mon, Jan 28, 2013 at 1:06 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote: this would not prevent, that people run into the exponential run time problem when using the naive pattern instead the anchored one, but this could be explained by a FAQ entry making the problem practically irrelevant. or do I still miss the relevant point? The very existence of naive patterns is the point. It is kind of a FAQ with the canonical answer being http://swtch.com/~rsc/regexp/regexp1.html. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Tue, 29 Jan 2013 00:10:26 -0700, Matt Welland estifo...@gmail.com wrote: Sorry, didn't paste in the second grep: Thanks for contributing this work-around. I guess it shows that there's a need for an easy, integrated grep to find code in the repository. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp d...@sqlite.org wrote: (1) grep function_name *.c */*.c# Adjust GLOB expressions as appropriate (2) fossil up prev (3) goto (1) Thank you. It works, although I also agree that grep within Fossil would be a good feature. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, 24 Nov 2012 13:57:41 +0100, 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)? Since this thread is a bit long, I'd like to ask: At this point, what is the solution to find a piece of code that can be in any revision in any file in the repository? I'm looking for a function that I know is a file somewhere, but don't know how to proceed. Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote: On Sat, 24 Nov 2012 13:57:41 +0100, 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)? Since this thread is a bit long, I'd like to ask: At this point, what is the solution to find a piece of code that can be in any revision in any file in the repository? I'm looking for a function that I know is a file somewhere, but don't know how to proceed. As I said early in the thread, deconstruct + grep. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote: On Sat, 24 Nov 2012 13:57:41 +0100, 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)? Since this thread is a bit long, I'd like to ask: At this point, what is the solution to find a piece of code that can be in any revision in any file in the repository? I'm looking for a function that I know is a file somewhere, but don't know how to proceed. As I said early in the thread, deconstruct + grep. :) Or maybe: (1) grep function_name *.c */*.c# Adjust GLOB expressions as appropriate (2) fossil up prev (3) goto (1) Repeat until the grep finds your function. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
Fossil, like many other VCSes, compresses revisions internally, and stores only some sort of deltas. I don't know how it is actually done, but usually, it's some sort of patches. FYI http://www.fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.wiki http://www.fossil-scm.org/index.html/doc/trunk/www/delta_format.wiki -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato Tcl'2013, Sep 23-27, New Orleans, LA, USA. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
Am Montag, 26. November 2012, 09:08:21 schrieb Andreas Kupries: Fossil, like many other VCSes, compresses revisions internally, and stores only some sort of deltas. I don't know how it is actually done, but usually, it's some sort of patches. FYI http://www.fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.w iki http://www.fossil-scm.org/index.html/doc/trunk/www/delta_format.wiki Ah, thanks. This makes grepping through the raw deltas less useful than a full text diff, because you could have a patch like int xyzy(char * bla) int xyzzy(char * bla) which is in fossil just a 'copy off1, len1; insert z; copy off2, len2;' patch. No way to find xyzzy as string in any insert. -- Bernd Paysan If you want it done right, you have to do it yourself http://bernd-paysan.de/ signature.asc Description: This is a digitally signed message part. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 9:53 PM, Bernd Paysan bernd.pay...@gmx.de wrote: Am Samstag, 24. November 2012, 20:28:16 schrieb j. v. d. hoff: what you propose could easily be filter out from a full recursive search backward through all revisions (and it would require such a search), right? Fossil, like many other VCSes, compresses revisions internally, and stores only some sort of deltas. I don't know how it is actually done, but usually, it's some sort of patches. You only have to grep through the patches, they show you when things were added and removed. Expanding all the history should not be necessary to implement this feature. Fossil's patches are not like SVN patches. Those are always whole lines. Fossil's patches may start mid-word (I think). ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
* Gilles gilles.gana...@free.fr [20121124 23:01]: On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp d...@sqlite.org wrote: 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. Does someone know of a good LGPL regex library that could easily be statically compiled in the Fossil binary? http://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines#Libraries tre? http://laurikari.net/tre/about/ qvb -- pica ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On 25/11/2012, at 9:24 AM, Richard Hipp wrote: On Sat, Nov 24, 2012 at 5:02 PM, Gilles gilles.gana...@free.fr wrote: On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp d...@sqlite.org wrote: 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. Does someone know of a good LGPL regex library that could easily be statically compiled in the Fossil binary? I have a regex library that I've been developing (from scratch) to go into SQLite for the REGEXP operator. It will serve. Jim Tcl (BSD licensed) has a small regex library which supports utf8. -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: 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. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ 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-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
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.comwrote: 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. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, 24 Nov 2012 14:18:55 +0100, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: 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 OK in 6 years of use, apparently, or at least has not mentioned it to me. neither did I, but the developers of `hg' did (the `hg grep' command). and I have found it quite useful by and then: there used to be some expression/phrasing/function in the document/source code some time ago and I recall it contained the pattern XYZ but not the details. question: in which revision(s) exactly is that stuff? when was it finally deleted?. is that such a rare situation for other folk? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ 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-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell vi...@viric.namewrote: 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.comwrote: 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? Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 08:59:58AM -0500, Richard Hipp wrote: On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell vi...@viric.namewrote: 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.comwrote: 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? I don't really know much, what I'd want. When I've used deconstruct, sometimes I wanted to grep files, sometimes tickets, sometimes checkin comments, sometimes in-file comments... I guess that 'grep' for only files, and some kind of FTS for the rest would be very nice. We use tickets extensively for bug tracking, but bugfixes happen as checkins, and sometimes we hit oh, I seem to remind that we had a case similar to this. And then I've to grep all to try to find out, even with different keywords, because who knows where I had that stored. But as after having the results, I end up wanting to check all results with the UI, I guess a ui option with links would be nicer. Thank you, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
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.namewrote: 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.comwrote: 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 --texttreat 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 --userlist the author (long with -v) -d --datelist 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. j. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: 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 --texttreat 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 --userlist the author (long with -v) -d --datelist 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-usershttp://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
Re: [fossil-users] howto `grep' through old revisions
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.comwrote: 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 --texttreat 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 --userlist the author (long with -v) -d --datelist 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
Re: [fossil-users] howto `grep' through old revisions
A grep though history would be a very useful functionality, There have been many times I'd have used it. Using sqlite3 glob or like for the pattern match would be more than adequate. If you need a regex just use the glob to select for the lowest common denominator and then pipe though egrep with the more complex regex to filter for exactly what you want. On Sat, Nov 24, 2012 at 7:35 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: 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.comwrote: 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 --texttreat 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 --userlist the author (long with -v) -d --datelist 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
Re: [fossil-users] howto `grep' through old revisions
Am Samstag, 24. November 2012, 08:59:58 schrieb Richard Hipp: 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? Hm, I'd rather show first and last revision where xyzzy is in, something like % fossil grep xyzzy ext1.txt 7c88a35016..cbaff03a91:ext1.txt:here we have the *xyzzy* string If you grep through some edit war, you will have many start..stop start..stop tuples. -- Bernd Paysan If you want it done right, you have to do it yourself http://bernd-paysan.de/ signature.asc Description: This is a digitally signed message part. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, 24 Nov 2012 20:05:55 +0100, Bernd Paysan bernd.pay...@gmx.de wrote: Am Samstag, 24. November 2012, 08:59:58 schrieb Richard Hipp: 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? Hm, I'd rather show first and last revision where xyzzy is in, something like % fossil grep xyzzy ext1.txt 7c88a35016..cbaff03a91:ext1.txt:here we have the *xyzzy* string If you grep through some edit war, you will have many start..stop start..stop tuples. what you propose could easily be filter out from a full recursive search backward through all revisions (and it would require such a search), right? I would not think this to be the best default behaviour (1000 revisions to process etc.). I think a stop at first hit default is more reasonable (and maybe more often than not the standard use case) -- 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
Re: [fossil-users] howto `grep' through old revisions
Am Samstag, 24. November 2012, 20:28:16 schrieb j. v. d. hoff: what you propose could easily be filter out from a full recursive search backward through all revisions (and it would require such a search), right? Fossil, like many other VCSes, compresses revisions internally, and stores only some sort of deltas. I don't know how it is actually done, but usually, it's some sort of patches. You only have to grep through the patches, they show you when things were added and removed. Expanding all the history should not be necessary to implement this feature. I would not think this to be the best default behaviour (1000 revisions to process etc.). I think a stop at first hit default is more reasonable (and maybe more often than not the standard use case) Stopping after a full page or so (like fossil timeline) also could be considered as a reasonable default. -- Bernd Paysan If you want it done right, you have to do it yourself http://bernd-paysan.de/ signature.asc Description: This is a digitally signed message part. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, 24 Nov, Bernd Paysan wrote: % fossil grep xyzzy ext1.txt 7c88a35016..cbaff03a91:ext1.txt:here we have the *xyzzy* string I would be in favour of this approach for a version control system with the concept of serial, incremental revision numbers where you can deduce from a range N..M what all the revisions in between are. However in case of hashes as revision numbers, you cannot easily - without invoking other commands to find out the timeline - deduce all matching revisions. I'd rather vote for a list all matching revisions in the --all case and the default behaviour to stop at the most recent match. Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp d...@sqlite.org wrote: 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. Does someone know of a good LGPL regex library that could easily be statically compiled in the Fossil binary? http://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines#Libraries ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
Stefan Bellon sbel...@sbellon.de wrote: I'd rather vote for a list all matching revisions in the --all case and the default behaviour to stop at the most recent match. I think there are three cases, the third being the earliest matching revision. Especially if the current revision is a match. Having the default list both most recent and earliest seems like a reasonable alternative. -- Sent from my Android phone. Please excuse my swyping.___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
What about just using regex(3)? It's included with BSD and quite possibly Linux distributions, but I have no way of checking. No idea how good the library is, but it might cut down on dependencies? -- James Turner ja...@calminferno.net ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 5:02 PM, Gilles gilles.gana...@free.fr wrote: On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp d...@sqlite.org wrote: 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. Does someone know of a good LGPL regex library that could easily be statically compiled in the Fossil binary? I have a regex library that I've been developing (from scratch) to go into SQLite for the REGEXP operator. It will serve. http://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines#Libraries ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] howto `grep' through old revisions
On Sun, 25 Nov 2012 00:17:44 +0100, j. v. d. hoff veedeeh...@googlemail.com wrote: would intgration of the lua library http://www.lua.org/ be a silly idea? it's under MIT licence, has very small footprint (quite probable smaller than a full fledged regex lib), and has a quite powerful pattern matching facility (somewhat different syntax than regex, but so what?) which can do everything that regex can (except alterations). who knows: it could even be useful as a configuration/scripting language of sorts If need be. Speaking of which, can Fossil be scripted, and if not, for what purposes could it be useful? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
