[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 20 May 2009 18:27:50 -0400

On Wed, May 20, 2009 at 4:53 PM, Stefan Sperling <stsp_at_elego.de> 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?
> If so, that's really bad. There were memory-related fixes for merge
> going into 1.6.2, but apparently they haven't fixed the problem you
> are seeing.

Let's not try to blame every problem on merge please? The reporter
has clearly indicated that the problem happens during commit. Commit
is commit, it does not matter if your working copy was edited by a
merge, a script or manual labor.

Mark Phippard
Received on 2009-05-21 00:28:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.