Re: [fossil-dev] autosetup 0.6.6 broke ./configure

Thanks, now on Fossil trunk. Are you going to roll this forward into the next autosetup release? -- Joe Mistachkin @ https://urn.to/r/mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin

Re: [fossil-dev] autosetup 0.6.6 broke ./configure

ome way we can get a version of autosetup that allows us to continue using our "--with" options? Changing them at this point would probably break a lot of Fossil build scripts, etc. -- Joe Mistachkin @ https://urn.to/r/mistachkin ___ fossil

Re: [fossil-dev] JSON wiki HTML rendering broken

ange, it does not appear to be logical. The moved if statement can never be true, because wiki_filter_mimetypes() cannot possibly return zero. -- Joe Mistachkin @ https://urn.to/r/mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http:/

Re: [fossil-dev] Time to release version 1.36?

How about something more like this: https://www.fossil-scm.org/fossil/info/7a14176ee0e6b093 -- Joe Mistachkin @ https://urn.to/r/mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin

Re: [fossil-dev] Time to release version 1.36?

Stephan Beal, can you comment on these changes please? Sent from my iPhone https://urn.to/r/mistachkin > On Oct 16, 2016, at 2:36 PM, BohwaZ wrote: > > Just posted the patch earlier on this list, here it is: > > Index: src/json_wiki.c >

Re: [fossil-dev] Time to release version 1.36?

Link to branch? Sent from my iPhone https://urn.to/r/mistachkin > On Oct 16, 2016, at 2:03 PM, BohwaZ wrote: > > Could we also include my fix for markdown in wiki pages for the JSON API? > > Thanks :) > ___ > fossil-dev mailing

Re: [fossil-dev] Time to release version 1.36?

are for important bug fixes. A couple are minor enhancements to functionality. I'm also aware of another set of changes for Git import/export that I think would be quite useful: https://urn.to/r/TV Are there any other changes that should be included in the release? -- Joe Mistachkin

[fossil-dev] Request for code review, "autosetupAndJimTcl" branch...

Please review the changes on the "autosetupAndJimTcl" branch, which updates the included autosetup and Jim with the latest code from upstream. Since both of these projects are maintained by Steve Bennett, it would be great to get his input as well. -- Joe Mistachkin @ https:

Re: [fossil-dev] "revert" branch review

leaned up some lingering bugs and edge cases, and > I've added tests to cover this stuff, too. > Which bugs? -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Branches in need of merging...

he's still interested in maintaining miniz (or passing it off to somebody else to maintain it)? I would really like to retain miniz support. However, if it becomes necessary to remove it, I've put the necessary changes (to completely remove it) on a bran

Re: [fossil-dev] Timeline graph rendering anomaly

near 2016-03-06. > > A small quirk, but a quirk nonetheless. > Yeah, that does seem wrong, it's missing the recent merge from trunk. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

[fossil-dev] Branches in need of merging...

By my estimation, there are around 7 branches (nearly?) ready to be merged. I've briefly looked over the changes; however, it would be good if others could review and/or provide feedback on them as well. -- Joe Mistachkin ___ fossil-dev mailing list

[fossil-dev] Last call for "testerCleanup" branch review...

I think this branch is ready and I'm planning on merging these changes to trunk on Tuesday, March 8th, 2016. Please feel free to raise objections. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http

Re: [fossil-dev] [fossil-users] Call for review / testing...

let you or Richard decide if that's > too cute or not, though. > I've modified the tests to replace "return" with "test_cleanup_then_return". Technically, not all the tests required this; however, the test cleanup is harmless when it's not needed. -- Joe Mistachkin ___

Re: [fossil-dev] Merge stash-fixes?

Andy Bradford wrote: > > Are there any other issues that could be addressed in the stash-fixes > branch? Basically it cleans up the ability to stash a rename. > If it fixes an issue (do we have a test case for it?) and passes all the existing tests, I say merge it. -- Jo

Re: [fossil-dev] Two different meanings for "default user"

Ross Berteig wrote: > > I propose to merge my ross-doc-env branch to trunk later tomorrow so > that more eyes can land on the documentation, unless there's something > grossly wrong that needs fixing first. > Looks great to me. Thanks for the hard work on improving

Re: [fossil-dev] Request for merge

6fc65f99c035dac > I've reviewed these changes briefly and I do not see anything obviously wrong with them; however, can other people with deeper knowledge of the web interface code please review them as well? -- Joe Mistachkin ___ fossil-

Re: [fossil-dev] Code coverage experiment

and merge them to trunk. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Code coverage experiment

> Thanks for the report. Fixed on trunk. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

[fossil-dev] Fossil build improvements...

and make on MinGW. Again, any feedback and/or testing for these changes would be greatly appreciated. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Test suite on Windows

tch, I did not notice that (Fossil is in my PATH). Fixed on trunk. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Test suite on Windows

Ross Berteig wrote: > > It seems as if the --no-repository option had no effect at all. Both > fossils are built fresh from tip of trunk this morning. > Sorry, that was a minor typo when refactoring. Should work now. -- Joe Mistachkin __

Re: [fossil-dev] Test suite on Windows

t-5.1 > * amend-comment-5.2 > * amend-comment-5.3 > * amend-comment-5.4 > It looks like these tests require "ed", which may not be available in MinGW? > > * merge_multi-4 > * merge_renames-5 > I'm still not sure on these. > > * rm-soft-relative-4

Re: [fossil-dev] Improving the test suite: file1.test

I believe the remaining "th1" errors should now be fixed on trunk. When TH1 hooks are enabled, the repository and checkout strings in the global state always get populated, which explains why the tests were passing when the TH1 hooks feature was a

Re: [fossil-dev] Improving the test suite: file1.test

ckout" procedure, which should allow them to pass as long as "tester.tcl" itself is being run from within the Fossil source checkout. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Improving the test suite: file1.test

with repo_init and > possibly more. > Those test files should work from outside of the tree now. For even more fun, try enabling Tcl integration and running the "th1-tcl.test" file... Also, while working on the th1-hooks test, I found a real issue with the timeline com

Re: [fossil-dev] Improving the test suite: file1.test

nt directory to be within the Fossil source checkout, run the Fossil command being tested, and then restore the current directory. The new test code that does this can be seen on trunk. Thanks for helping us improve this stuff. -- Joe Mistachkin __

Re: [fossil-dev] Improving the test suite: file1.test

Ross Berteig wrote: > > I still have errors from th1.test: 3 errors out of 255 tests run. They > are th1-checkout-2, th1-globalState-1, and th1-globalState-8. > Thanks, should be fixed now. I have no idea about the "merge*" failur

Re: [fossil-dev] RFC: new manifest card: G

e type of thing that user-defined tags are perfect for? -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Re: [fossil-dev] Current status of make test?

(i.e. the "th1.test" and "file1.test" test files must be run from within the Fossil checkout). I'm not sure about "merge-utf-27-23" and "merge-utf-27-32". They failed here last night as well and I'm not sure why. -- Joe Mistachkin __

Re: [fossil-dev] Current status of make test?

Ross Berteig wrote: > > I figure the first step to building test cases for JSON support is to > prove I can build a fossil that passes its existing tests. Apparently > that isn't the case. > Please try setting the TEMP environment variable to a directory writable by the curren

Re: [fossil-dev] Current status of make test?

tcl" if it's not set. > > The tests on tag release now finish without halting, but not without > failures. > Can you run just the failing test files with the "-verbose" option and send the output? -- Joe Mistachkin ___ fossil-dev

Re: [fossil-dev] Fixed segfault in th_lang.c

Apparently, a fix was done on a branch, but never made it to trunk? https://www.fossil-scm.org/fossil/info/f2d87242503d7a7d Revised trunk to match it (with a minor style tweak): https://www.fossil-scm.org/fossil/vinfo/c66083eded992cc -- Joe Mistachkin

Re: [fossil-dev] Time to release Fossil version 1.34?

There seems to be a timeline issue: https://system.data.sqlite.org/index.html/timeline?n=50=all=1 The [2c6bdf20ea] merge check-in has two entries for each of the modified files. -- Joe Mistachkin ___ fossil-dev mailing list fossil-dev

Re: [fossil-dev] [Q] Update .ignore-glob to include build artifacts on Linux

Chris Drexler wrote: So what do you think? Is it OK to add or rather not? I don't think they should be in ignore-glob, no. It would [normally] prevent the extras command from seeing them and the clean command from removing them. -- Joe Mistachkin