On Fri, Jan 17, 2014 at 8:32 PM, John Keeping wrote:
> Presumably you are OK with this having the same latency as the existing
> cache mechanism. The simplest implementation will probably be to keep
> the existing "cache valid?" check and re-scan repositories as we
> currently do.
Or even just s
On Fri, Jan 17, 2014 at 8:29 PM, Konstantin Ryabitsev wrote:
>
> The process that updates the repositories may not have permissions to
> send SIGUSR1 to the fcgid process -- either because they are running as
> different users or because there are SELinux policies preventing it.
>
> It's really be
On Fri, Jan 17, 2014 at 02:29:19PM -0500, Konstantin Ryabitsev wrote:
> On 17/01/14 01:22 PM, Jason A. Donenfeld wrote:
> >> But scan for repos is caught by the cache most of the time, and
> >> > presumably even if we run persistently we still need to do that
> >> > periodically (or use inotify); o
On 17/01/14 01:22 PM, Jason A. Donenfeld wrote:
>> But scan for repos is caught by the cache most of the time, and
>> > presumably even if we run persistently we still need to do that
>> > periodically (or use inotify); or do we just rely on the process being
>> > replaced when the set of repositor
On Fri, Jan 17, 2014 at 5:53 PM, John Keeping wrote:
> But scan for repos is caught by the cache most of the time, and
> presumably even if we run persistently we still need to do that
> periodically (or use inotify); or do we just rely on the process being
> replaced when the set of repositories
On Fri, Jan 17, 2014 at 06:09:15PM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 17, 2014 at 5:38 PM, Jason A. Donenfeld wrote:
> > On Fri, Jan 17, 2014 at 5:28 PM, John Keeping wrote:
> >> I really can't see this being sensible without moving to libgit2. As
> >> long as we stick with libgit.a
On Fri, Jan 17, 2014 at 5:38 PM, Jason A. Donenfeld wrote:
> On Fri, Jan 17, 2014 at 5:28 PM, John Keeping wrote:
>> I really can't see this being sensible without moving to libgit2. As
>> long as we stick with libgit.a then we need to fork for each request so
>> I'm not sure there's much benefi
On Fri, Jan 17, 2014 at 05:38:29PM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 17, 2014 at 5:28 PM, John Keeping wrote:
> > I really can't see this being sensible without moving to libgit2. As
> > long as we stick with libgit.a then we need to fork for each request so
> > I'm not sure there's
On Fri, Jan 17, 2014 at 5:28 PM, John Keeping wrote:
> I really can't see this being sensible without moving to libgit2. As
> long as we stick with libgit.a then we need to fork for each request so
> I'm not sure there's much benefit to supporting FastCGI without moving
> to something that lets u
On Fri, Jan 17, 2014 at 05:12:26PM +0100, Jason A. Donenfeld wrote:
> Here's what I'm thinking about for the next release (or releases?):
>
> + FastCGI support
I really can't see this being sensible without moving to libgit2. As
long as we stick with libgit.a then we need to fork for each reques
Hi guys,
Here's what I'm thinking about for the next release (or releases?):
+ FastCGI support
+ More malloc()/free() cleanups
+ git-blame support
+ git-grep support
+ HTML5 compliance
+ More filters everywhere
+ Expanded test suite
+ Line number anchors highlighting the current line
+ sendfile()
11 matches
Mail list logo
