On 12/28/17, Richard Hipp wrote:
>
> The "fossil server" command *should* be sufficient for this. However,
> it doesn't get used that much. Most people run from a proper HTTP
> server of some kind. Consequently, it is possible for bugs to linger
> in "fossil server" without
On 12/28/17, Richard Hipp wrote:
>
> Running multiple copies of the new fossil-stress.tcl script
> (https://www.fossil-scm.org/fossil/file/tools/fossil-stress.tcl) from
> a linux box against a windows laptop confirms that the "fossil server"
> command on Windows sometimes latches
Dear,
Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's
say < 10 developers each with their own clone ?
Or should a proper HTTP server be used as front end to SCGI mode of fossil?
From some quick-n-dirty tests (yeah, on a Windows server, not the best of all
ideas
On 12/28/17, Olivier Mascia wrote:
>
> Is "fossil server" generally deemed sufficient for a small LAN (lab) of
> let's say < 10 developers each with their own clone ?
> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
The "fossil server" command
> Le 28 déc. 2017 à 15:04, Richard Hipp a écrit :
>
> On 12/28/17, Richard Hipp wrote:
>>
>> Running multiple copies of the new fossil-stress.tcl script
>> (https://www.fossil-scm.org/fossil/file/tools/fossil-stress.tcl) from
>> a linux box against a windows
> Le 28 déc. 2017 à 12:26, Olivier Mascia a écrit :
>
> Dear,
>
> Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's
> say < 10 developers each with their own clone ?
> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
>
>
> Le 28 déc. 2017 à 13:51, Richard Hipp a écrit :
>
> On 12/28/17, Olivier Mascia wrote:
>>
>> Is "fossil server" generally deemed sufficient for a small LAN (lab) of
>> let's say < 10 developers each with their own clone ?
>> Or should a proper HTTP server
> Le 28 déc. 2017 à 16:55, Olivier Mascia a écrit :
>
>> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
>> now.
>
> I haven't yet come to bottom of it, but using IP (IPv4) in the URL (instead
> of name) changes it all!! There seem to be a high
> Le 28 déc. 2017 à 17:18, Richard Hipp a écrit :
>
> There is one thread per connection in the parent process, which allows
> the parent to manage multiple simultaneous incoming connections. As
> each thread gets a complete HTTP request, it writes that request into
> a
On 12/28/17, Warren Young wrote:
>>
>> Even the Windows server starts a new process to handle each request.
>> It just does so using system() rather than fork().
>
> That leaves me wondering what the threads are used for then, if not to
> implement a thread-per-connection
On Wed, Dec 27, 2017 at 11:56:31PM +0100, Olivier Mascia wrote:
> > Le 27 déc. 2017 à 23:24, Joerg Sonnenberger a écrit :
> >
> > On Wed, Dec 27, 2017 at 10:10:21PM +, bch wrote:
> >> On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia wrote:
> >>
> >>> Hello,
>
On 12/28/17, Warren Young wrote:
>
> drh, I seem to recall messages about non-free()’d buffers in the Fossil
> server code, where the patch was rejected with the argument that the forked
> child is about to die anyway, so why bother freeing the buffer. That
> doesn’t really
> Le 28 déc. 2017 à 17:37, Olivier Mascia a écrit :
>
> The quick/easy/dirty/temporary fix before completing the proper support
> (server-side) of IPv4+IPv6 would be to simply adjust the hint.ai_family
> initialisation in http_socket.c::socket_open to read:
>
> #ifdef _WIN32
On Dec 28, 2017, at 9:11 AM, Richard Hipp wrote:
>
> On 12/28/17, Warren Young wrote:
>>
>> drh, I seem to recall messages about non-free()’d buffers in the Fossil
>> server code, where the patch was rejected with the argument that the forked
>> child is
On Dec 28, 2017, at 6:11 AM, Olivier Mascia wrote:
>
> *** time skew *** server is slow by 106.6 seconds
…snip…
> I'll have a close look in the next weeks at the source code of the Windows
> server feature of Fossil. The warning "*** time skew *** will certainly be
>
On Dec 28, 2017, at 4:26 AM, Olivier Mascia wrote:
>
> Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's
> say < 10 developers each with their own clone ?
> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
That’s how I
On Dec 28, 2017, at 7:42 AM, Olivier Mascia wrote:
>
> server on macOS, client on Windows (server 2016 and server 2012 R2) is OK.
> Server and client on same Windows box, through localhost is comparable (just
> slightly slower) to server macOS and client Windows.
That’s not
> Le 28 déc. 2017 à 15:42, Olivier Mascia a écrit :
>
> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
> now.
I haven't yet come to bottom of it, but using IP (IPv4) in the URL (instead of
name) changes it all!! There seem to be a high price
On Dec 28, 2017, at 8:55 AM, Olivier Mascia wrote:
>
>> Le 28 déc. 2017 à 15:42, Olivier Mascia a écrit :
>>
>> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
>> now.
>
> I haven't yet come to bottom of it, but using IP (IPv4)
>
> Any pointers are appreciated.
>
>
I created a brand new repo with zero commits and I was able to clone
it with fossil server running. So it looks like an issue with the repo
itself, perhaps enabling fossil debug on the binary caused an issue?
>
> --
> ---
> inum: 883510009027723
> sip:
On 12/28/17, jungle Boogie wrote:
> Hi All,
>
> I cannot clone a fossil repo running on a reaspberry pi.
> --fossil-debug was originally used but since then, multiple fossil
> binaries have been built with it disabled.
Sounds to me like you are still running the older
On 28 December 2017 at 12:02, Richard Hipp wrote:
> On 12/28/17, jungle Boogie wrote:
>> Hi All,
>>
>> I cannot clone a fossil repo running on a reaspberry pi.
>> --fossil-debug was originally used but since then, multiple fossil
>> binaries have been
Thus said Warren Young on Thu, 28 Dec 2017 08:20:21 -0700:
> I'm pretty sure I've never seen Fossil crash in the years I've been
> running it.
I've had it dump core a few times but those were generally due to bugs
that were quickly fixed.
Andy
--
TAI64 timestamp: 40005a4540f3
Hi All,
I cannot clone a fossil repo running on a reaspberry pi.
--fossil-debug was originally used but since then, multiple fossil
binaries have been built with it disabled.
>fossil clone http://10.7.0.82:8080 cpp_projects.f
Round-trips: 1 Artifacts sent: 0 received: 0
server replies with
On 12/28/17, Thomas wrote:
>
> This could be an option too:
> #ifndef IPV6_V6ONLY
> #define IPV6_V6ONLY 27
> #endif
It compiles with that. But it doesn't work. So for now, I think
we'll just stick with IPv4-only servers for "fossil server" on windows
- at least until
Oh, and this is not a Windows thingy.
For Linux:
#include
#include
http://man7.org/linux/man-pages/man7/ipv6.7.html
On 2017-12-29 02:23, Thomas wrote:
On 2017-12-29 01:17, Richard Hipp wrote:
On 12/28/17, Olivier Mascia wrote:
To get a proper dual-stack socket, the
On 2017-12-29 01:17, Richard Hipp wrote:
On 12/28/17, Olivier Mascia wrote:
To get a proper dual-stack socket, the socket must be created with AF_INET6
first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...)
When I try to do this I get: error C2065: 'IPV6_V6ONLY':
On 12/28/17, Olivier Mascia wrote:
> To get a proper dual-stack socket, the socket must be created with AF_INET6
> first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...)
When I try to do this I get: error C2065: 'IPV6_V6ONLY': undeclared identifier
MSVC 2015
--
D. Richard
28 matches
Mail list logo