> From: Greg Stein <gst...@gmail.com> > On Wed, Jul 20, 2011 at 09:23, <kmra...@rockwellcollins.com> wrote: > > Greg Stein <gst...@gmail.com> wrote on 07/19/2011 06:53:12 PM: > >> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato <cmpil...@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.
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.
