You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by rh...@apache.org on 2011/07/20 12:49:03 UTC
svn commit: r1148693 - /subversion/branches/1.7.x/STATUS
Author: rhuijben
Date: Wed Jul 20 10:49:02 2011
New Revision: 1148693
URL: http://svn.apache.org/viewvc?rev=1148693&view=rev
Log:
* STATUS: Nominate r1148588 and cast a -0 vote.
Modified:
subversion/branches/1.7.x/STATUS
Modified: subversion/branches/1.7.x/STATUS
URL: http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1148693&r1=1148692&r2=1148693&view=diff
==============================================================================
--- subversion/branches/1.7.x/STATUS (original)
+++ subversion/branches/1.7.x/STATUS Wed Jul 20 10:49:02 2011
@@ -63,12 +63,25 @@ Candidate changes:
confirmation from an ra_svn developer that this is the
right way to fix this problem)
- * r1148566
- Fix a memory leak in svn merge.
- Justification:
- Memory leaks are bad.
- Votes:
- +1: stsp
+ * r1148566
+ Fix a memory leak in svn merge.
+ Justification:
+ Memory leaks are bad.
+ Votes:
+ +1: stsp
+ -0: rhuijben (r1148588 fixes the immediate problems and this code can use
+ a bit more cleanup before backporting. See also the
+ dev@s.a.o thread for gstein's concerns)
+
+ * r1148588
+ Use a subpool for each log item in ra_serf instead of allocating all the
+ structures in the main parser pool and store a variable in the right pool.
+ Justification:
+ Reduces memory consumption during log processing (E.g. svn log, svn merge,
+ svn mergeinfo), and provides a proper scratch pool to receivers for
+ further memory usage reduction.
+ Votes:
+ +1: rhuijben
Approved changes:
=================
Re: svn commit: r1148693 - /subversion/branches/1.7.x/STATUS
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 20, 2011 at 10:49:03AM -0000, rhuijben@apache.org wrote:
> + * r1148566
> + Fix a memory leak in svn merge.
> + Justification:
> + Memory leaks are bad.
> + Votes:
> + +1: stsp
> + -0: rhuijben (r1148588 fixes the immediate problems and this code can use
> + a bit more cleanup before backporting. See also the
> + dev@s.a.o thread for gstein's concerns)
Hmmm.. what "immediate problems" is r1148588 fixing?
Are you suggesting that r1148588 alone fixes the memory leak?
Because it doesn't.
Have you tried the merge described in the log message of r1148566
with r1148566 backed out? The leak is still present when I try this.
See also my reply to gstein's mail:
http://svn.haxx.se/dev/archive-2011-07/0583.shtml
Of course we can clean things up more, but that is no reason
not to merge r1148566 into 1.7.x.