Re: [fossil-users] check-in-edit branch ready?
On Fri, Jul 31, 2015 at 6:50 AM, jungle Boogie wrote: > Related to testing, have you or anyone used AFL[0] on Fossil? I know > Michael (its creator) ran it against sqlite and reported dozens of > findings to drh and as of 3.8.10[1], AFL is apart of the tests for > sqlite. > > I'd run AFL against fossil if I knew how but when looking at it, I'm > not sure where to being. > i recall the sqlite threads regarding this, but it seems, to me, to be geared more towards programs taking "very flexible" forms of input (script languages and similar). For fossil it could very well result in a garbage repo without that being an error, per se (e.g. it would produce random branch names (of endless variety)). It could, i think, be useful for fuzz-testing the json api, but i'm not convinced that applying it to the fossil cli would be all that useful. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] AFL. Was: check-in-edit branch ready?
On 7/31/15, jungle Boogie wrote: > > Related to testing, have you or anyone used AFL[0] on Fossil? I know > Michael (its creator) ran it against sqlite and reported dozens of > findings to drh and as of 3.8.10[1], AFL is apart of the tests for > sqlite. > > I'd run AFL against fossil if I knew how but when looking at it, I'm > not sure where to being. > > [0] http://lcamtuf.coredump.cx/afl/ > [1] https://www.sqlite.org/testing.html#aflfuzz > It would be good to run AFL against the "fossil http" command, I think. The way this would work is that you first develop a library of valid HTTP requests. Put each request in a separate file and put them all in a single directory, say "in". You what to have a few dozen distinct requests that invoke different web pages: /timeline, /doc, /brlist, /tree, etc. with various query parameters. You will also need a test repository which should probably be made read-only (so that none of the AFL test commands actually change the repository). Rebuild Fossil using the AFL tool-chain: CC=afl-gcc configure; make Then run: afl-fuzz -i in -o out -- fossil http readonly-repo.fossil Then start fixing the bugs that are reported -- 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
[fossil-users] Wiki Header & Footers
The Wiki Headers and Footers are not under any versioning control or history, correct? I am planning on creating a file to source control them, but wanted to make sure I'm not doing something that is already built in. ___ 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] 'mv' semantics
On 30 July 2015 at 10:44, Michai Ramakers wrote: > On 30 July 2015 at 00:07, Joe Mistachkin wrote: >> >> Michai Ramakers wrote: >>> >>> I was unclear; this is the corresponding timeline: >>> >>> === 2015-07-29 === >>> 19:58:39 [70b61c707b] *CURRENT* x (user: michai tags: trunk) >>>DELETED d/dd/f >>>DELETED d/f >>>ADDED e/dd/f >>>ADDED e/f >>> 19:57:26 [998d26af68] a (user: michai tags: trunk) >>>ADDED d/dd/f >>>ADDED d/f >>> 19:56:53 [07d0f795af] initial empty check-in (user: michai tags: trunk) >>> >> >> Yeah, I've seen that happen to; however, in this case I believe it's a >> red herring. The --hard option makes no different in how the timeline >> is presented. >> >> I'm not saying there isn't an issue with the timeline; I'm saying it's >> unrelated to the --hard option. > > alright; I'll test this more in the afternoon. ok, today instead of yesterday then, sorry :) I don't think I understand what goes on here; I can't see the difference between filesystem-mv (no fossil involved), and 'fossil mv --hard', really. I looked at some posts w.r.t. mv/rm/extra/changes from the past, and some people feel strongly about what should or must not happen - I'm not one of those, really, I just don't understand how it works now. Michai ___ 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] 'mv' semantics
Michai Ramakers wrote: > > I don't think I understand what goes on here; I can't see the > difference between filesystem-mv (no fossil involved), and 'fossil mv > --hard', really. > Sometimes, Fossil will show a rename as a delete/add pairing. I've seen this happen when I edit the file at the same time I'm renaming it (and in some other circumstances). I'm not 100% sure what causes this behavior; however, it seems "mostly harmless". > > I looked at some posts w.r.t. mv/rm/extra/changes from the past, and > some people feel strongly about what should or must not happen - I'm > not one of those, really, I just don't understand how it works now. > Yes, I remember those discussions. I think most (?) of the underlying issues in those discussions have largely already been addressed. -- Joe Mistachkin ___ 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] 'mv' semantics
On 31 July 2015 at 18:05, Joe Mistachkin wrote:
>
> Michai Ramakers wrote:
>>
>> I don't think I understand what goes on here; I can't see the
>> difference between filesystem-mv (no fossil involved), and 'fossil mv
>> --hard', really.
>>
>
> Sometimes, Fossil will show a rename as a delete/add pairing. I've seen
> this happen when I edit the file at the same time I'm renaming it (and in
> some other circumstances). I'm not 100% sure what causes this behavior;
> however, it seems "mostly harmless".
ok; from what you said, I understood that this could be partly a
timeline-issue/-feature/-flaw.
I think I'm missing the point of what 'mv --hard' should do (before or
after the recent fix).
What I see now, is that 'fossil mv --hard dir1 dir2' has, apart from
printing 2 lines ('RENAME \nMOVED_FILE ...'), the exact same
effect as doing "mv dir1 dir2' (fossil not involved).
I can't see any difference. After either command, files in 'dir2' are
seen as extra files, files in 'dir1' are seen as missing, and so on.
Resulting timelines look the same as far as I can see.
When using 2 commands to move 'dir1' to 'dir2', as in
1) mv dir1 dir2
2) fossil mv dir1 dir2
...I could create a check-in containing that single action - renaming
a dir. When viewing the history of a file in 'dir2' or 'dir1' as per
'/finfo' page, one could traverse the history accross the
rename-action. That is not reallly possible when using 'fossil mv
--hard'.
Perhaps moving dirs using 'mv --hard' like this is a corner-case, or
I'm still not getting the point :-) Isn't 'mv --hard' the same as *nix
'mv' in my case..?
Thx,
Michai
___
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] 'mv' semantics
On 29 July 2015 at 21:29, Joe Mistachkin wrote: > > Michai Ramakers wrote: >> >> Right... creating the target-dir 'd2' beforehand worked in my case; >> any subdir existing under 'd' seems to be moved under 'd2' afterwards. >> > > I think the following change will fix the issue: > > https://www.fossil-scm.org/fossil/info/b86127e187a00bfc BTW, "fossil mv" behaves different than *nix "mv" if source and destination are directories; I guess this is by design. mkdir dir1 echo gone > dir1/f fossil addr fossil ci -m kiwi mkdir x echo precious > x/f fossil mv --hard dir1 x cat x/f # 'gone' fossil undo # 'nothing to undo' Silly example - I am just playing around a bit to see how things work. (Behaviour the same before and after recent fix, naturally.) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Query to return non-propagating tags applied to commits?
'Lo. Is there a straightforward SQL query that will, given a tag name, show me the commits to which that tag is applied (if any), taking into account any "cancel tag" events? M ___ 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] AFL. Was: check-in-edit branch ready?
Hi Dr. Hipp, On 31 July 2015 at 04:16, Richard Hipp wrote: > On 7/31/15, jungle Boogie wrote: >> >> Related to testing, have you or anyone used AFL[0] on Fossil? I know >> Michael (its creator) ran it against sqlite and reported dozens of >> findings to drh and as of 3.8.10[1], AFL is apart of the tests for >> sqlite. >> >> I'd run AFL against fossil if I knew how but when looking at it, I'm >> not sure where to being. >> >> [0] http://lcamtuf.coredump.cx/afl/ >> [1] https://www.sqlite.org/testing.html#aflfuzz >> > > It would be good to run AFL against the "fossil http" command, I think. > > The way this would work is that you first develop a library of valid > HTTP requests. Put each request in a separate file and put them all > in a single directory, say "in". You what to have a few dozen > distinct requests that invoke different web pages: /timeline, /doc, > /brlist, /tree, etc. with various query parameters. You will also need > a test repository which should probably be made read-only (so that > none of the AFL test commands actually change the repository). > Sounds like a good plan Only thing I don't understand is, what's a valid http request? curl https://www.fossil-scm.org/index.html/timeline > -- > D. Richard Hipp > d...@sqlite.org -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] AFL. Was: check-in-edit branch ready?
On 31 July 2015 at 04:16, Richard Hipp wrote: > Rebuild Fossil using the AFL tool-chain: > > CC=afl-gcc configure; make > > Then run: > > afl-fuzz -i in -o out -- fossil http readonly-repo.fossil > > Then start fixing the bugs that are reported Doing all of those steps: [-] Looks like the target binary is not instrumented! The fuzzer depends on compile-time instrumentation to isolate interesting test cases while mutating the input data. For more information, and for tips on how to instrument binaries, please see /usr/local/share/doc/afl/README. When source code is not available, you may be able to leverage QEMU mode support. Consult the README for tips on how to enable this. (It is also possible to use afl-fuzz as a traditional, "dumb" fuzzer. For that, you can use the -n option - but expect much worse results.) [-] PROGRAM ABORT : No instrumentation detected Location : check_binary(), afl-fuzz.c:6567 And when substituting fossil with sqlite3 (same steps applied), it starts the application. I don't have anything to test but it's at least instrumented itself and prepared for take off. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
