[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: <kmradke_at_rockwellcollins.com>
Date: Wed, 20 Jul 2011 12:02:02 -0500

> From: Greg Stein <gstein_at_gmail.com>
> 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
> >> 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
> >> 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
> > 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.

I guess I would consider a large increase in memory use a release
blocker/enough to make serf no longer the default. In my experience,
10's of thousands of files is no longer a "large" test case.

Somewhat off-topic, but there was also previous concern that
the multiple connections that serf uses might overly stress some
larger servers. Do we have any idea how many additional connections
a typical server would see? For example, if I see 1000 concurrent
connections to a server with neon, will I need to support 10000 shorter
connections with serf? (The 10x I chose is purely arbitrary and
not based upon any knowledge of the actual differences...)

> 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).

Good to hear we already know the potential solution!

Kevin R.
Received on 2011-07-20 19:02:39 CEST

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