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

Re: svn_repos_get_logs3 and unbounded memory use

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-02-09 17:57:23 CET

On 2/9/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> Garrett Rooney wrote:
> > On 2/8/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> >>On 2/8/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> >>
> >>>Hrm. So, the additional calls to svn_fs_node_history() simply populate
> >>>a structure. But you'd have to call svn_fs_history_prev() twice, once
> >>>to get to the history location you reported in your last iteration, and
> >>>then again to reach the next new and interesting location. That could
> >>>really get costly in terms of performance, I imagine. Especially over
> >>>the likes of 1200 paths. Still, memory is a fixed resource; Time not so
> >>>much.
>
> [...]
> > I'm not sure if this is the kind of approach we want to taks (it would
> > be really nice if a call with a more reasonable number of paths could
> > go faster by keeping the histories open, for example), but I imagine
> > we're going to need to go down this path at some point unless we want
> > to put a hard cap on the total number of paths you're allowed to pass
> > to log.
>
> Sorry to jump in with what may be just an ignorant question, but could you
> briefly explain whether such a large number of paths is passed in common
> every-day scenarios (and, if so, why) or just in some extreme use cases like
> "svn log */*/*.c".

I was able to reproduce it via 'svn log URL --targets FILE', where
FILE contains a list of paths within URL. I have no idea what's
actually causing this in practice, but I have seen numerous crashes
that were caused by this on svn.apache.org, so something's doing it.
So if I had to guess, I'd say it's an extreme edge case, but it does
actually occur.

Regardless of how easy it is to reproduce this problem with the
command line tools, the fact that it can happen at all via the
protocol/API requires that we fix it.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 9 18:32:45 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.