[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7.0-beta2 this afternoon

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 20 Jul 2011 11:54:50 -0400

On Wed, Jul 20, 2011 at 09:23, <kmradke_at_rockwellcollins.com> wrote:
> Greg Stein <gstein_at_gmail.com> wrote on 07/19/2011 06:53:12 PM:
>> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato <cmpilato_at_collab.net>
>> wrote:
>> >...
>> > release-readiness?   What about ra_serf's "default-ness" -- is it in the
>> > appropriate state based on that library's readiness at this moment?
>> The only pending serf issue is my testing of a fix to memory blowup in
>> ra_serf when somebody checks out a repository root (ie. 10's of
>> thousands of files across trunk, tags, and branches). Personally, I
>> think it is a bug that could be fixed in 1.7.1, but I'm shooting to
>> get the code tested for a 1.7.0 release. It is currently disabled on
>> trunk and 1.7.x, but a simple two-line fix enables it.
> I've seen revisions where millions (yes, I said millions) of files were
> changed at one time, so I feel ra_serf needs to be able to handle
> 10's of millions of files in trunk alone during an update without
> needing TBs of memory...
> (I'm not saying I would recommend using Subversion in this way, just
>  that I have seen older versions abused in amazing ways...)

Not saying it shouldn't be fixed... just saying that I'm unsure that
it is a *release-blocker*. Or more precisely, that it is an issue that
would cause serf to no longer be the default.

In any case, I've got all the code written, and a test plan and code
for verification. It should make 1.7.0 without much problem (assuming
that I haven't horrendously messed up my approach).

Received on 2011-07-20 17:55:23 CEST

This is an archived mail posted to the Subversion Dev mailing list.