On 3/17/15, Jan Nijtmans jan.nijtm...@gmail.com wrote:
2015-03-17 22:18 GMT+01:00 Richard Hipp d...@sqlite.org:
What is the proposed purpose of the --docker option to fossil init?
Presumably it has something to do with the Docker container system.
But I do not understand what that is, exactly
the head of that branch running on the main server so
that you can try it out:
https://www.fossil-scm.org/fossil/timeline?y=ci
Please provide feedback.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http
on the
identity of the repository that is doing the push.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
branch to trunk?
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http
it was the make clean and not the fossil rebuild that
cleared the problem
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
But I want Fossil to "just work" for El Capitan, including building
out-of-the-box.
On 10/21/15, Ben Summers <b...@bens.me.uk> wrote:
>
> It's just the headers which are missing. You just need to build it with an
> older OS X SDK.
>
> Ben
>
>
>>
The following fixed it:
brew install openssl
./configure -with-openssl=/usr/local/Cellar/openssl/1.0.2d_1
On 10/21/15, Richard Hipp <d...@sqlite.org> wrote:
> But I want Fossil to "just work" for El Capitan, including building
> out-of-the-box.
>
> On 10/21/15,
)Notes and/or description for a branch
(8)Quick links to formatting rules when editing wiki
(9)Enhance the formatting rules for markdown
(10) Handle symlinks by default
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev
ki-render, but for markdown syntax.
>
> I use "test-markdown-render" as command name and add it at the end of
> wiki.c (I decide to make a separate command, because test-wiki-render
> take a few "fossil-wiki" only options)
>
> Is there any objections if I comm
Any objections to cutting the Fossil 1.35 release sometime early next week?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
iest, due to other scheduling issues.
So the question becomes: Is your enhancement important enough to
delay the release by two months? Or is it better to get 1.35 out
Tuesday morning and deal with your enhancement for 1.36?
--
D. Richard Hipp
d...@s
tephan 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
>
--
D. Richard Hipp
d...@sqlite.org
_
listing on systems where fusefs is not supported, just as
commands like "cgi" and "artifact" and "zip" are currently omitted
from "fossil help" (unless you include the --all option).
--
D. Richard Hipp
d...@sqlite.org
___
posal is that we standardize on the /foo/x form for all generated
> links. Justification: they simply look better :/.
>
> If there are no objections...
>
The problem comes up when "name" contains special characters, such as "/" or "?"
--
D. Richard Hipp
d...@sq
reviously just being ignored.
>
> Unless you have any other issues I need to fix, I'm happy with the state
> of the branch as it is now.
I've been seeing your branch on the timeline and thinking I need to
look at it. But I'm really swamped right now. I'll get to it as soon
as I can. Keep
On 2/27/17, Andy Bradford <amb-fos...@bradfords.org> wrote:
> Thus said Richard Hipp on Mon, 27 Feb 2017 21:50:43 -0500:
>
>> (9) There are no changes to the file formats, other than relaxing the
>> size constraint on artifact hashes - allowing hash to be greater
On 2/28/17, Richard Hipp <d...@sqlite.org> wrote:
>
> (4) There are no hash options. You cannot choose to use any hash
> algorithm other than SHA3-256 for new content.
>
> (6) The only complication to upgrading is that you need to update all
> of your fossil (or fossil.
remote side should
also be Fossil 2.0 or later so that the new SHA3 hashes can be
understood.
(6) The only complication to upgrading is that you need to update all
of your fossil (or fossil.exe) binaries to version 2.0 at the same
time.
All of the above is subject to change. Please pro
m inclined
now to go with the shorter SHA3-224.
Your feedback is important!
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
rhaps
after a delay of a few days.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
probably document the limitation.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
ve bigger fish to fry at the
moment.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
ating only SHA3 hash names.
(3) There is a new "sha3sum" command made available for your convenience.
Further documentation updates are likely prior to the release, but at
this point the code is feature complete and ready for testing. Please
repo
n 10%.
Works fine from here. Could it be the network on your end?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
is to add
support for multiple hash algorithms.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
ell go with 256. But there are situations where the full hash is
shown. One example is the "fossil status" command. There are many
others. Those extra 8 bytes of hash on 256 versus 224 are starting to
push the limits of what you can display with an 80-column tty window.
--
D. Ric
. It is unused now. So I simply removed it.
Let me know if you find anything else wrong.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
ortment
of precompiled binaries to the download page. If anything, I'd like
to cull a few. Linux and OpenBSD being obvious candidates since
"./configure;make" works so well on those platforms.
--
D. Richard Hipp
d...@sqlite.org
___
f
On 11/19/16, Richard Hipp <d...@sqlite.org> wrote:
> On 11/19/16, Andy Goth <andrew.m.g...@gmail.com> wrote:
>> Is this extension documented? What is the precise behavior? Are there
>> guarantees that it will be preserved throughout future versions of
>> SQLite?
. So, it is looking at the most recent leaf of the branch.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
; incorporate your words about the special behavior of max() and min() into
> the SQLite documentation?
If you send suggested text, I'll insert it for you. The documentation
for SQLite is managed by a separate Fossil repo
(https://www.sqlite.org/docsrc/timeline).
--
D. Richard
s that happens.
(2) The /brlist definition is easier to compute.
>
> On Nov 19, 2016 06:32, "Richard Hipp" <d...@sqlite.org> wrote:
>
>> On 11/19/16, Andy Goth <andrew.m.g...@gmail.com> wrote:
>> >
>> > If I understand correctly, the baseline
in() function determines which row is used to
> compute bare columns. Do you want to document this behavior, or do you
> want to reserve the right to change it later?
That behavior is undefined. We reserve the right to change it.
--
D. Richard Hipp
d...@sqlite.org
__
SQLite version 3.16.0 is now checked into Fossil. Perhaps this would
be a good time to do another release of Fossil.
Key enhancements (in my opinion):
* The "fossil all ui" command
* Checkbox widgets in submenus
* Improvements to the "fossil sql" command
-
On 1/2/17, jungle Boogie <jungleboog...@gmail.com> wrote:
> On Jan 2, 2017 11:15 AM, "Richard Hipp" <d...@sqlite.org> wrote:
>>
>> SQLite version 3.16.0 is now checked into Fossil. Perhaps this would
>> be a good time to do another release of Fossil.
On 1/2/17, Richard Hipp <d...@sqlite.org> wrote:
> Three bugs found already (one reported by E.Pasma on the SQLite
> mailing list, and two more found by the developers while working on
> the E.Pasma bug)
To be clear, E.Pasma found his problem using SQLite 3.15.0. He just
h
gt;
> Any suggestions as to which to prefer?
(1)
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On 12/23/16, Martin Gagnon <eme...@gmail.com> wrote:
>
> I've push a small change related to temporary file handling when using
> "gdiff"
Merged.
I haven't run gdiff in many years. Ever since the --tk option on diff
was invented, that's all I have used.
--
D. Ric
Now that SQLite 3.18.0 has landed, I think it would be good to do a
Fossil 2.2 release. Objections? Concerns?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin
For reference, I uploaded two lists of distinct UserAgent strings:
https://www.fossil-scm.org/tmp/robot-agents.txt
https://www.fossil-scm.org/tmp/non-robot-agents.txt
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev
SQLite.org sees about 20x the volume by any
measure.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
I don't understand the details of this issue, but my instinct would be
to use the T card to avoid an incompatibility.
On 3/31/17, Jan Nijtmans <jan.nijtm...@gmail.com> wrote:
> 2017-03-30 21:24 GMT+02:00 Richard Hipp:
>> On 3/30/17, Jan Nijtmans <jan.nijtm...@gmail.co
On 3/15/17, Roy Marples <r...@marples.name> wrote:
>
> I didn't use the term Open Source once in the "Fossil is not social"
> section, I just described the model.
> I have edited the blog post to reflect this.
>
Thanks for clarifying your blog.
--
that one
SQL statement.
Aside: Roy, I though you gave up on Fossil?
https://roy.marples.name/blog/goodbye-fossil
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/lis
oice for any
cathedral-style open-source project. If you want to say that GitHub
(or Mercurial or something else) works better for bazaar-style
projects, that it fine. But I think it is incorrect to say that those
others are better for *all* open-source projects.
--
D. Richard Hipp
d...@sqlite.or
$40 USD to purchase the domain.
I'm inclined to ignore their offer, as adding fossil-scm.com is just
one more DNS entry to maintain. But I am open to acquiring
fossil-scm.com (and pointing it to exactly the same webserver as
fossil-scm.org) if others think that would be a good idea.
Your thoughts?
If there are no objections, I will take the current tip of trunk as
the 2.2 release.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
the download.html page is
now only working if you update to the latest trunk version;
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
t; specific test case is verifying that a hash prefix is allowed.
Fixed now on trunk.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On 3/13/17, Ross Berteig <r...@cheshireeng.com> wrote:
> I seem to have the test suite bee in my bonnet this week.
I, for one, am hoping that bee hangs around :-)
It's ok to do your test debugging on trunk, if you want to go ahead
and merge your branch.
--
D. Richard Hipp
d...@s
ion here would be to change the RE to be
"([0-9a-f]{40,64})". Does that fix the problem?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On 2/28/17, Richard Hipp <d...@sqlite.org> wrote:
>
> release Fossil 2.0 and Fossil 2.1 simultaneously. The only difference
> between these two version will be that Fossil 2.0 still always
> generates SHA1 hashes on new content whereas Fossil 2.1 generates only
> SHA3 hash
On 2/26/17, Richard Hipp <d...@sqlite.org> wrote:
> I propose that the next release of Fossil be called "Fossil 2.0"
An alpha version of Fossil 2.0 is now live on the main fossil website:
https://www.fossil-scm.org/
That same Fossil instance also runs SQLite: htt
On 3/31/17, Jan Nijtmans <jan.nijtm...@gmail.com> wrote:
> 2017-03-31 17:04 GMT+02:00 Richard Hipp:
>> I don't understand the details of this issue, but my instinct would be
>> to use the T card to avoid an incompatibility.
>
> Thanks! Does that mean that the "
On 8/12/17, Richard Hipp <d...@sqlite.org> wrote:
>
> I went a slightly different route...
Having thought about this more, I'm thinking now that I might go back
to Andy's approach....
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev
ossil. Please audit to
confirm that I did not miss anything.
I don't feel a particular need to rush out a new release containing
this fix. But I am open to arguments to the contrary, if you feel
differently.
--
D. Richard Hipp
d...@sqlite.org
t; perhaps worse because it allows remote execution of commands:
>
> fossil clone "ssh://somehost//some/path;rm -rf /" clone.fossil
>
I went a slightly different route and simply added additional error
checking on the code that constructs the "ss
this page should check many, many things. The more the
better, it seems to me.
Suggestions for new things to check are welcomed.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqli
%29%20onerror=eval%28src%29%3E
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
de diff utility does begin having problems for lines
longer than 255 characters, but it continues to work.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/
e: programs on CentOS 7 are built to expect that stack size, and
> there is some setting in the ELF header that declares the required stack
> size, so that execl() knows the program won’t even run correctly if loaded
> under the set limit.
> ___
> fossil-dev mailing list
>
; http://wanderinghorse.net/home/stephan/
> "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-dev m
to improve the diff, please speak up.
FWIW, this came up while trying to fix a bug in SQLite - specifically
the query planner problem that was patched at
https://www.sqlite.org/src/timeline?c=87aceb41
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev ma
LENGTH_MASK_SZ would help, unless
one or more lines of your input file were extraordinarily long.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
ow. Please try again with the latest and report
any additional problems.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
he size to be rounded up rather than rounded down. I
have now changed this to round to the nearest.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On 8/23/17, Richard Hipp <d...@sqlite.org> wrote:
> The problem originates at this check-in:
> https://fossil-scm.org/fossil/timeline?c=2375d6cbce933267
I do not understand what benefit the check-in above provides. But it
does definitely change the semantics of a lot of operations
me enhancements to the "fossil
attachment" command to allow the project-specific test scripts to add
appropriate attachments with tags.
Thoughts?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.or
3693ce85 is
stuck using the legacy timeline format, and does not respond to the
timeline configuration settings for adjusting the formatting.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.s
ptions. Please send
your feedback, even if it is just "+1 Option 3".
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
the ability put a tag on a wiki page.
That is a new capability that we would need to add.
Nor is it possible to put a tag on a branch.
We could create a special tag that associates a check-in with a wiki
page without any low-level file format enhancements, though.
--
D. Richard Hipp
between wiki pages and
equivalently named branches and check-ins?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
, that would be great. Thanks.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
not well known outside the USA nor by
spelling checkers, so I changed the comment to spell out "if and only
if".
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On 10/18/17, Richard Hipp <d...@sqlite.org> wrote:
> On 10/18/17, Warren Young <war...@etr-usa.com> wrote:
>> On Oct 18, 2017, at 3:44 AM, Warren Young <war...@etr-usa.com> wrote:
>>>
>>> The more web apps that ship with stringent Content-Security-Polic
it with tcl-fossil-repo as database:
That is not guaranteed. It might be true of many or even most
repositories. But it is not universally true.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.
led).
>
> 4. The idea to change order by clause (e. g. sort by rowid and not by
> date) sounds plausible (and I believe ordering by any date is wrong, at
> least by the usage of option "--git").
>
> Regards,
> Sergey.
>
> 03.05.2018 19:55, Richard Hipp wrote:
&g
On 6/6/18, Kyle Shannon wrote:
> Our security team found another XSS, shall I forward the link to the list?
Yes, please
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.
On 6/20/18, Andy Goth wrote:
> Check-in ccf50f0619 adds email.c to main.mk, but there is no such file. Did
> you (drh) mean to do "fossil add"?
>
> For now I'm having to stick with 7001228a09.
Thanks. Should be fixed now.
--
D. Richar
10
> Merge fork
> from :108967
> merge :108890
> M 100644 :86007 doc/define.n
>
> commit refs/heads/mistake
> MARK :108962
> committer jan.nijtmans 1524612720 +
> data 71
> Merge 8.6 (bug-fix and test-case for Tcl_UtfAtIndex with TCL_UTF_MAX=4)
> from :108958
> merge :108960
> M 100644 :86010 generic/tclUtf.c
> M 100644 :86003 tests/string.test
> M 100644 :86010 generic/tclUtf.c
> M 100644 :86003 tests/string.test
>
> <<< /EXCERPT >>>
>
>
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
been in heavy use without
problems for a couple of months. The current code does contain an
alpha version of SQLite, but all the SQLites pass so I think that is
fine.
If there are no serious objections, I will do a release from trunk
within 24 hours.
--
D. Richard Hipp
d...@sqlite.org
meta-data. Such information is current
transmitted using file-naming conventions. Breaking it out into
explicit meta-data seems to be a better design choice.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev
creates a
new process to handle each request, and so the exit() function still
operates as a (very fast and efficient) garbage collector following
each request.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailing
declarations to occur before any code within
the block.
On 1/15/18, Christian Stærk <x...@borderworlds.dk> wrote:
> On 01/14/18 18:06, Richard Hipp wrote:
>
>> On 1/14/18, Christian Stærk <x...@borderworlds.dk> wrote:
>>> What do you think? Is this desirable?
>>
mercur...@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
er from the occasional fork that happens due
to a race.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
o separate bugs. This is yet a third.
They should all be fixed now, by separate check-ins.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On 1/14/18, Christian Stærk <x...@borderworlds.dk> wrote:
>
> What do you think? Is this desirable?
>
I'm certainly willing to consider it, but I want to see some examples
before committed to this path.
--
D. Richard Hipp
d...@sqlite.org
___
ot. And yet, Fossil's self-hosting
repo and the SQLite repo are both running of the tip of trunk. This
should tell you that occasional odd behaviors might be seen, but that
there is high confidence that the content is completely safe and
secure.
--
D. Richard Hipp
d..
On 7/26/18, Ryan Noll (Mailing List) wrote:
> I have been experiencing a lot of the SQLITE_NOTICE(283)
This is not an emergency. You can safely ignore these warnings. I am
working to fix them for the next release, but you should not feel
pressured to take a fix right away.
--
D. Richard H
ps://fossil-scm.org/forumtest1/forumpost/10fe5ccbc8 - please
consider posting follow-ups there, as a test of the new forum system.
If you encounter problems, reply to this legacy mailing list, or
directly to me via private email.
--
D. Richard Hipp
d...@sqlite.org
io challenge?
This is an interesting problem, for which I do not have an immediately
solution. There is no way to skip the captcha at this time. I will
investigate further. Thanks for reporting the issue.
--
D. Richard Hipp
d...@sqlite.org
___
fossil
On 11/20/18, Stephan Beal wrote:
> Is fossil-dev still the preferred place for dev-specific topics or is the
> forum preferred for that?
fossil-dev is still alive, but I think the forum is preferred. So,
"yes" to both questions.
--
D. Richard Hipp
94 matches
Mail list logo
