On 8 Sep 2010, at 18:32, Richard Hipp wrote:
> A key point is that the sync mechanism does not know anything about the
> meta-information or the internal format of the artifacts. All sync knows is
> that there is some set of artifacts on one side of the connection, and
> another set of artifa
On 26 June 2010 20:59, Michal Suchanek wrote:
> Indeed, the loss is at the end in case of web pages, parts which are
> missing in the middle are result of inserting different streams so
> SCSU would not suffer more breakage than other encodings. Still there
> is no apparent benefit in using it.
F
On 26 June 2010 13:47, Michal Suchanek wrote:
> On 25 June 2010 21:37, Owen Shepherd wrote:
>> On 25 June 2010 19:36, Michal Suchanek wrote:
>>> On 25 June 2010 20:18, Owen Shepherd wrote:
>>>> One of the reasons that I'm a fan of SCSU is that, with even a
On 25 June 2010 19:36, Michal Suchanek wrote:
> On 25 June 2010 20:18, Owen Shepherd wrote:
>> One of the reasons that I'm a fan of SCSU is that, with even a
>> relatively simple encoder, it produces output which is comparable in
>> efficiency to that of most legac
One of the reasons that I'm a fan of SCSU is that, with even a
relatively simple encoder, it produces output which is comparable in
efficiency to that of most legacy encodings.
On 25 June 2010 18:53, Michal Suchanek wrote:
> On 25 June 2010 18:09, Owen Shepherd wrote:
>> The troub
The trouble is that UTF-8 is a poor standard. It bloats many texts, is
quite expensive to parse, and has only one redeeming feature: It never
creates embedded nulls. I suppose that it shares its encoding with
ASCII is a feature too, but only a minor one.
Personally, I think that most systems shoul
On 25 June 2010 11:15, Sergey Sfeli wrote:
>
> Ruslan Popov wrote:
>
> > I've tried to use Fossil on russian version of Windows 7. I made commit with
> > russian text in comment, when I run the UI and look at timeline, I saw that
> > russian text looks like squares.
>
> Why don't just use text edi
On 2 June 2010 18:11, Joshua Paine wrote:
> Only 127.0.0.1 is privileged, right? So can we just not trust
> X-Forwarded-For: 127.0.0.1 no matter who says it, and not worry if
> X-Forwarded-For is abused otherwise?
>
No. Fossil keys its login cookies off the user's IP address. If the user
can pr
SCGI is so simple that its pretty much impossible to implement wrongly.
The only brokenness that I've seen is that nginx' SCGI handler (Which is a
somewhat unmaintained 3rd party module) doesn't accept status: lines like
its supposed to. The work around took one line, however. If I ever get
around
On 31 May 2010 15:01, Paul Ruizendaal wrote:
>
> >> I'm really short on time right now, but I will try to help you in
> making
> >> this a cross-platform patch. I can test on WinXP, Linux and FreeBSD.
> Can
> >> you test on OS-X?
> >
> > No, sorry. I can add OpenSolaris to the testing platforms t
For those so interested, the modification is now being self hosted. See
http://fossil.e43.eu/fossil/. Anonymous cloning is allowed.
- Owen.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/li
On 31 May 2010 07:49, Paul Ruizendaal wrote:
> Hi folks,
>
> Two remarks:
>
> 1. I'm happy that more and more people are contributing to Fossil, but I'm
> also a bit concerned about the increasing Posix dependence. The https code
> builds in a dependence on libssl, and now the below patch is Posi
I've finished modifying Fossil to support SCGI. Some notes:
- I rewrote the accept loop of the server/ui command at the same time. It
no longer uses select with a timeout in order to reap child processes;
instead, a signal handler is installed for SIGCHLD in order to reap them and
main
On 30 May 2010 02:59, Richard Hipp wrote:
>
> "CGI ... is highly inefficient". The http://www.sqlite.org/ and
> http://www.fossil-scm.org/ websites are both run off of the same server
> (check the IP addresses on the domains). The HTTP server there is a simple
> home-brew job implemented as a si
On 30 May 2010 00:53, Michael McDaniel wrote:
> I wound up running lighttpd for the sole purpose of serving fossil
> via cgi scripts. lighttpd is pretty lightweight on resources.
>
> ~Michael
>
The idea has crossed my mind, but the idea of having to maintain another set
of configuration files
We are currently experimenting with setting up a Fossil server, but have
encountered a bit of an issue: Fossil doesn't seem to support being operated
behind a proxy. As we wish to run Fossil on port 80, and to do so it must
sit behind our primary web server, this is a bit of an issue.
The ideal so
I operate in an environment without CGI support (We run an Nginx web server,
which
doesn't support CGI). Implementing Fossil using a bunch of it's own servers
behind
Nginx as a proxy is undesirable for a multitude of reasons: It means
configuring a
Fossil service for every repository, which mea
On Wed, 29 Apr 2009 21:37:53 +0100, Stephan Beal wrote:
>
> Once one is used to SpiderMonkey, the basic stuff is not at all
> difficult to do (though i will never understand their (undocumented)
> threading API). However... being able to extend fossil via JS is,
> however, arguably of little use s
On Wed, 29 Apr 2009 16:55:26 +0100, wrote:
> i've done quite a lot with JS embedding in non-browser contexts, eg a JS
> SQLite3 wrapper:
>
> http://code.google.com/p/v8-juice/wiki/PluginSQLite
>
> and might be able to be of assistance here. Another interesting project
> in
> this area is:
>
> ht
19 matches
Mail list logo
