On Thursday 23 June 2005 06:33, John Szakmeister wrote:
> On Wednesday 22 June 2005 07:02, Akin, Klaus wrote:
> > Hi,
> >
> > The recipe to get a large memory usage on the svn client:
> >
> > -- first check out some data for example:
> > svn co http://svn.collab.net/repos/svn/trunk subversion
> > -- delete all .svn files in this folder
> >
> > -- create the repository
> > svnadmin create memoryleak
> > -- make it general writeable
> >
> > --start the server
> > start svnserve -d -r .
> >
> > -- import the data to folder subversion
> > svn import subversion svn://<machine>/memoryLeak/subversion/ -m
> > "import" -- create an empty dir
> > svn mkdir svn://<machine>/memoryLeak/empty -m "creating empty dir"
> > -- checkout the empty folder
> > svn co svn://<machine>/memoryLeak/empty test
> > -- merge
> > svn merge svn://<machine>/memoryLeak/empty
> > svn:// <machine>/memoryLeak/subversion/ test
> >
> > During the merge the process is increasing to 60MB. It is never
> > decreasing during merge. The data in the test folder is about 53MB.
>
> Thanks, I was able to verify this on my Linux box as well (except it
> grew to nearly 80MB). I made a couple of quick patches and it seemed
> to stop at around 12.5MB. I'm running through the test suite and such
> right now. But since this is in working copy code (which is notoriously
> complex), I'll post it a patch on dev@ list later tonight. Hopefully,
> we can get this in for the next release (but no guarantees as 1.2.1 is
> right around the corner).
Here's the patch I was using. I'm posting here to the dev@ list in hopes
that someone with a little more knowledge behind the merge operation can
see if this is acceptable. From what I can tell, a number of operations
were using the pool in the merge baton, but they didn't need that long of
a lifetime. So I switched them to using the subpool instead. It passes
'make check'.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 24 02:29:33 2005