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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature