A new feature was recently added to Fossil that allows it to deny expensive
requests (such as blame or tarball on a large repository) if the server
load average is too high. See
http://www.fossil-scm.org/fossil/doc/tip/www/server.wiki#loadmgmt for
further information.
This new feature was
On Wed, Mar 12, 2014 at 6:40 AM, Richard Hipp d...@sqlite.org wrote:
A new feature was recently added to Fossil that allows it to deny expensive
requests (such as blame or tarball on a large repository) if the server
load average is too high. See
I host my fossil repository on a private server. As a little background, I
do mostly scripting work and keep all my projects in separate branches.
This has worked great for me and I will continue to use this method.
However, I am almost finished with a project I would like to host on
chiselapp
On 10/03/2014 22:24, Richard Hipp wrote:
The diff-generator in Fossil is unable to cope with lines longer than
8192 bytes.
That could be changed. (It's a #define, though there are adverse
consequences for making it too large.) But is a diff on a file with
huge lines like that really useful?
On Wed, Mar 12, 2014 at 1:13 PM, Andreas Kupries
andre...@activestate.comwrote:
On Wed, Mar 12, 2014 at 6:40 AM, Richard Hipp d...@sqlite.org wrote:
And if you have alternative suggestions about how to keep a light-weight
host running smoothly under a massive Fossil request load, please
On Wed, Mar 12, 2014 at 6:13 PM, Andreas Kupries
andre...@activestate.comwrote:
How sensible do you think would it be to have a (limited-size)
(in-memory|disk) cache to hold the most recently requested tarballs ?
That way a high-demand tarball, etc. would be computed only once and
then served
The current Fossil implementation runs a separate process for each HTTP
request. So an in-memory cache wouldn't be helpful. It has to be disk-
based.
Does not FastCGI do exactly the opposite?
RR
2014-03-12 18:25 GMT+01:00 Richard Hipp d...@sqlite.org:
On Wed, Mar 12, 2014 at
On Wed, Mar 12, 2014 at 1:26 PM, Stephan Beal sgb...@googlemail.com wrote:
In my experience, most proxies won't cache for requests which have URL
parameters. Whether or not that's generally true, i can't say. For static
content (lots of what fossil serves is static), the URLs can/should be
On Wed, Mar 12, 2014 at 6:31 PM, Ramon Ribó ram...@compassis.com wrote:
The current Fossil implementation runs a separate process for each HTTP
request. So an in-memory cache wouldn't be helpful. It has to be disk-
based.
Does not FastCGI do exactly the opposite?
FastCGI requires
On Mon, Mar 10, 2014 at 06:31:25PM -0400, Ron Wilson wrote:
On Sat, Mar 8, 2014 at 5:17 PM, Chad Perrin c...@apotheon.net wrote:
Should I take it at this point that --incremental is deprecated and
should not be used or expected to be present in future Fossil versions?
So far, I have seen
On Wed, Mar 12, 2014 at 5:04 PM, Chad Perrin c...@apotheon.net wrote:
I'm stuck in kind of a no-win situation with this, then. It's not
really appropriate to log a bug in an issue tracker without knowing it's
a bug, but nobody will tell me if it's a bug, how I should judge whether
it's a
11 matches
Mail list logo
