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

Re: Possibility new memory leak of 1.6.x Subversion

From: B. Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Sun, 24 May 2009 21:26:21 +0200

On Sun, May 24, 2009 at 18:30, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sun, May 24, 2009 at 06:01:01PM +0200, B. Smith-Mannschott wrote:
>> I tried without success to reproduce this issue under Mac OS X. This
>> would tend to support the idea that this bug is Windows-only.
>>
>> 1. Created new repository on a 1.5.2 server. (that's what I've got on
>> my server).
>> Using a 1.6.2 client:
>> 2. Checked out empty root of said repository (svn://) into local working copy.
>> 3. Created 50 directories of 10 directories of 50 empty files.
>> 4. svn add all 50 top-level directories, which effectively adds everything.
>> 5. svn commit
>>
>> The commit ran to completion. The client's RSIZE grew to about 50MB
>> during the commit.

[snip]

>> 1. Created a new repository locally using svnadmin 1.6.2
>> 2. Checked out empty root of said repository (file://) into local working copy.
>> 3. Created 10000 empty files in this directory.
>> 4. svn add all files.
>> 5. svn commit.
>>
>> The commit ran to completion. The client's RSIZE grew to about 22MB
>> during the commit.

[snip]

> Can you try adding all files from boost?
> http://dfn.dl.sourceforge.net/sourceforge/boost/boost_1_39_0.tar.bz2
>
> Also, a vendor-branch scenario would be a nice test.
> E.g. import an older version of boost into /vendor/boost,
> copy it to /trunk, checkout /vendor/boost, make the working
> copy match boost-1.39 e.g. by using svn_load_dirs.pl or
> http://svn.clifford.at/tools/trunk/svnemboss.sh and commit,
> and then try to do a merge from /vendor/boost to /trunk and
> commit the result.

I went ahead an did this both on a linux machine (svn 1.6.0) and on my
mac (svn 1.6.2).

- created a empty repository
- check out (file://) root into a working copy
- unpack boost 1.39.0; rename it to 'trunk'
- svn add trunk;
- svn commit trunk
- copy trunk to a folder named vendor
- svnemboss contents of boost 1.35.0 into vendor (* svnemboss requires
a small fix for svn 1.5+ *)
- commit the resulting changes to vendor
- merge the change just commited on vendor into trunk
- commit the changes to trunk

The various add, commit and merge operations all resulted in resident
sizes (RSIZE in top on Mac OS X) between 50 MB and 80 MB. Doing the
actual merge and committing the results were the most expensive, at
about 80 MB. More expensive than, say, the initial commit of trunk.

In summary: I don't see any unreasonable memory consumption in this
scenario when I perform it on Mac OS X and Linux.

// ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2353340

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-24 21:27:22 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.