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

Re: svn commit: r1102690 - in /subversion/trunk/subversion: libsvn_ra_serf/replay.c tests/cmdline/svnsync_tests.py

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 13 May 2011 16:46:04 -0400

On 05/13/2011 04:28 PM, Kamesh Jayachandran wrote:
>>Naturally, in such situations, you don't want to open your file batons in
>>pools that will be destroyed when their parent directory baton's pool is
>>also destroyed. You need instead for file baton's to have lifetimes that's
>>about as long as the whole editor drive.
> Thanks Mike for explaining this. Then such a long living pool would cause
> similar leak!!!

Indeed, we've seen exactly this kind of memory bloat issue in the client's
commit code. One alternative is to send text-deltas inline with the rest of
the commit, but that means potentially transmitted *alot* of data only to
find that the last of those files is out of date, the commit fails, etc.
That's just not acceptable. So the onus is on the editor implementation to
keep it's file batons "tight" and not abuse the pool passed to open_file()
and add_file().

I've just committed some notes in the svn_delta_editor_t API docs about this.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-05-13 22:46:35 CEST

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.