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

Re: [PATCH] [Issue 1751] file not switched if it is the same in source and destination

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-03-21 21:43:00 CET

makl <makl@tigris.org> writes:

>>>+ /* Read DIRPATH's entries. */
>>>+ SVN_ERR (svn_wc_entries_read (&entries, dirpath, TRUE, subpool));
>>
>> I know you copied this code, but the pool handling isn't correct.
>> It should be using pool here, not subpool.
>
> Potentially we read a big bunch of entries and i think the memory should
> be freed as soon as possible. And for the recursive case, after
> completing the operation we have all entries of the complete working
> copy in memory. This sounds not correct for me.

Subversion's standard pool pattern is described in HACKING. The point
of the subpool is to handle the iteration, so it *must* be cleared
within the loop. This means that any memory that must persist from
one iteration to the next cannot be allocated from the subpool. You
don't need to worry about the amount of memory allocated by one-shot,
non-iterative, allocations as it is the callers responsibility to
provide a suitable pool, and clear it if required.

As it happens svn_wc_entries_read is special, the entries are
allocated from the pool used to open the access baton and not from the
pool parameter. In most cases calling svn_wc_entries_read doesn't
allocate any additional memory.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 21 21:43:18 2004

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.