On Dec 2, 2009, at 6:39 PM, Hyrum K. Wright wrote:
> Hi all.
>
> Gather up your holiday cheer, for I would like to propose a gift to the
> Subversion user community: Subversion 1.6.7. I know that folks have been
> busy with the ASF transition as of late, but our users have been busy finding
On Mon, Dec 14, 2009 at 07:59:10PM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
> One of our users reported the bug in Subversion trunk in checking out
> of Gentoo's "sunrise" supplemental repository. I can reproduce this problem:
> $ svn co svn://overlays.gentoo.org/proj/sunrise/reviewed su
On Mon, Dec 14, 2009 at 10:42:23AM -0800, Paul Querna wrote:
> The attempt to change back to native malloc/free was kicked off by
> Ben's report. We had it in trunk for more than 2 months, we tried
> optimizing it, but we just couldn't get it reliably into the same
> level of performance.
Would y
On Wed, Oct 14, 2009 at 8:23 PM, Julian Foad wrote:
> Author: julianfoad
> Date: Wed Oct 14 18:23:05 2009
> New Revision: 40041
>
> Log:
> * STATUS: Update my review status on r39019.
>
> Modified:
> branches/1.6.x/STATUS
>
> Modified: branches/1.6.x/STATUS
> URL:
> http://svn.collab.net/viewvc
One of our users reported the bug in Subversion trunk in checking out
of Gentoo's "sunrise" supplemental repository. I can reproduce this problem:
$ svn co svn://overlays.gentoo.org/proj/sunrise/reviewed sunrise
...
Asunrise/app-misc/rainlendar-lite
Asunrise/app-misc/rainlendar-lite/metada
On Mon, Dec 14, 2009 at 10:26 AM, Justin Erenkrantz
wrote:
> Just to note - in Amsterdam earlier this year, the APR/httpd folks
> ripped out pools and replaced it with a straight malloc/free
> implementation and the performance across the board was horrific even
> with the "best" malloc replacemen
Justin Erenkrantz wrote:
> On Mon, Dec 14, 2009 at 10:34 AM, C. Michael Pilato
> wrote:
>> Mark Phippard tipped me off to this.
>>
>> Glad to hear that APR folk took the report seriously enough to investigate
>> the matter. Did anyone there happen to look at the fact that MaxMemFree
>> seems to
On Mon, Dec 14, 2009 at 10:34 AM, C. Michael Pilato wrote:
> Mark Phippard tipped me off to this.
>
> Glad to hear that APR folk took the report seriously enough to investigate
> the matter. Did anyone there happen to look at the fact that MaxMemFree
> seems to not work at all, or that pools appe
Mark Phippard tipped me off to this.
Glad to hear that APR folk took the report seriously enough to investigate
the matter. Did anyone there happen to look at the fact that MaxMemFree
seems to not work at all, or that pools appear not to be automagically
defragmentable?
Justin Erenkrantz wrote:
On 12/14/2009 08:23 AM, C. Michael Pilato wrote:
Some time ago, Ben Collins-Sussman shared with us some of the Google teams'
findings about APR's memory subsystem[1]. In his mail, he says (among other
things) the following:
Are there any plans to get this into APR upstream? I could definitely
Just to note - in Amsterdam earlier this year, the APR/httpd folks
ripped out pools and replaced it with a straight malloc/free
implementation and the performance across the board was horrific even
with the "best" malloc replacement libraries. So, that code was
reverted...see:
http://mail-archive
2009-12-14 18:56:50 Philip Martin napisał(a):
> Alexander Thomas writes:
>
> > On Mon, 2009-12-14 at 13:47 +, Philip Martin wrote:
> >> Alexander Thomas writes:
> >>
> >> > [[[
> >> > Allow build against the full path to neon-config.
> >> >
> >> > * build/ac-macros/neon.m4
> >> > (SVN_LIB
Alexander Thomas writes:
> On Mon, 2009-12-14 at 13:47 +, Philip Martin wrote:
>> Alexander Thomas writes:
>>
>> > [[[
>> > Allow build against the full path to neon-config.
>> >
>> > * build/ac-macros/neon.m4
>> > (SVN_LIB_NEON): Modified to accept full path to neon-config. Fixed doc
>>
On Mon, 2009-12-14 at 13:47 +, Philip Martin wrote:
> Alexander Thomas writes:
>
> > [[[
> > Allow build against the full path to neon-config.
> >
> > * build/ac-macros/neon.m4
> > (SVN_LIB_NEON): Modified to accept full path to neon-config. Fixed doc
> > string accordingly.
> > ]]]
>
>
Some time ago, Ben Collins-Sussman shared with us some of the Google teams'
findings about APR's memory subsystem[1]. In his mail, he says (among other
things) the following:
Over at Google, we simply hacked APR to *never* hold on to blocks
for recycling. Essentially, this makes apr_pool_de
Thanks.
Masaru.
2009/12/14 Bert Huijben :
>> -Original Message-
>> From: masaru tsuchiyama [mailto:m.tma...@gmail.com]
>> Sent: zaterdag 12 december 2009 13:36
>> To: Stefan Sperling
>> Cc: Hyrum K. Wright; dev@subversion.apache.org
>> Subject: Re: [PATCH] Fix warning PRJ0009 when building
Julian.
I want to draw your attention to something that you may or may not realize
about designing for the BDB backend. The 'trail' objects are (generally)
representative of Berkeley DB transactions -- that part I'm sure you know.
But you might not realize the value of keeping transactions as sma
Jon Foster wrote:
> I'd like to report a problem with mod_dav_svn and repository
> hooks. I had a bug in my post-revprop-change script, but all I
> saw was:
>
> > $ svn propedit --revprop -r 19 svn:log
> > svn: DAV request failed; it's possible that the repository's
> > pre-revprop-change hook ei
Alexander Thomas writes:
> [[[
> Allow build against the full path to neon-config.
>
> * build/ac-macros/neon.m4
> (SVN_LIB_NEON): Modified to accept full path to neon-config. Fixed doc
> string accordingly.
> ]]]
What's the rationale for this change? Does it fix something?
--
Philip
> -Original Message-
> From: masaru tsuchiyama [mailto:m.tma...@gmail.com]
> Sent: zaterdag 12 december 2009 13:36
> To: Stefan Sperling
> Cc: Hyrum K. Wright; dev@subversion.apache.org
> Subject: Re: [PATCH] Fix warning PRJ0009 when building with Visual Studio
>
> Hi.
>
> I'll send the p
Hi,
I'd like to report a problem with mod_dav_svn and repository
hooks. I had a bug in my post-revprop-change script, but all I
saw was:
> $ svn propedit --revprop -r 19 svn:log
> svn: DAV request failed; it's possible that the repository's
> pre-revprop-change hook either failed or is non-exist
[[[
Allow build against the full path to neon-config.
* build/ac-macros/neon.m4
(SVN_LIB_NEON): Modified to accept full path to neon-config. Fixed doc
string accordingly.
]]]
-Alexander Thomas(AT)
Index: build/ac-macros/neon.m4
22 matches
Mail list logo
