kfogel@collab.net writes:
> philip@tigris.org writes:
>> Log:
>> Fix part of issue 1635. Control client memory use when deleting
>> lots of targets.
>
> I might be missing something, but it looks like this commit controls
> pool usage by creating a subpool at the top of a do_entry_deletion(),
> then destroying it at the bottom. That is, it's not really an
> iteration pool, it's a function-body pool.
>
> Usually, we would create an iteration subpool in the caller(s), and
> simply pass the subpool to do_entry_deletion(). In this case the
> caller is ultimately an editor drive, but still, wouldn't the same
> principle apply?
You are correct. It turns out that the server fixes (r9033/r9044)
already solve the problem for ra_svn, and ra_local was never
affected. That only leaves ra_dav, how about this
Index: subversion/libsvn_ra_dav/fetch.c
===================================================================
--- subversion/libsvn_ra_dav/fetch.c (revision 9049)
+++ subversion/libsvn_ra_dav/fetch.c (working copy)
@@ -1788,7 +1788,7 @@
svn_stringbuf_set(rb->namestr, name);
parent_dir = &TOP_DIR(rb);
- subpool = parent_dir->pool;
+ subpool = svn_pool_create (parent_dir->pool);
pathbuf = svn_stringbuf_dup(parent_dir->pathbuf, subpool);
svn_path_add_component(pathbuf, rb->namestr->data);
@@ -1797,6 +1797,7 @@
SVN_INVALID_REVNUM,
TOP_DIR(rb).baton,
subpool) );
+ svn_pool_destroy (subpool);
break;
default:
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 15 23:30:31 2004