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

Re: Memory leak with 1.6.x clients

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 20 May 2009 16:57:31 -0400

Stefan Sperling wrote:
> On Wed, May 20, 2009 at 09:45:12PM +0100, Stefan Sperling wrote:
>>> To reproduce this issue create a new repository and check in an older
>>> Linux Kernel 2.6 once that is done get a newer Linux Kernel 2.6 and merge
>>> that with what you checked in. Then do the svn commit and watch top.
>>> Notice the memory use for the process increasing rapidly as the dots are
>>> displayed by the process. In my case, OOM killed the process with a -9.
>> How are you doing this? Are you adding the entire Linux source tree to
>> the working copy and then try to commit it? If so, this is a really a
>> use case where, according to issue #1964, svn import should be used
>> instead of svn add, *by design* (as bad as the design may be).
>> I am surprised that this works with 1.5.x, even.
>
> I didn't properly read the above paragraph you wrote before replying.
> Sorry about that.
>
> So the problem is that svn bombs out while committing the result
> of a giant merge, right? Not the result of a plain "svn add"
> followed by "svn commit"? I.e. there is no other way of carrying
> out the commit, and because it fails it is not possible to execute
> the merge you want to do?

Maybe "merge" in the instructions above really boils down to something like
"untar the newer 2.6 kernel sources atop a working copy containing older 2.6
kernel sources"? In that case, this would be merely a commit of
(potentially many) changed files.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2335096

Received on 2009-05-20 22:58:07 CEST

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.