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

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