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

Re: Memory leak remains in 1.6.3?

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 24 Jun 2009 17:44:30 +0200

Andy Levy wrote:
> On Wed, Jun 24, 2009 at 11:19, Stefan Küng<tortoisesvn_at_gmail.com> wrote:
>> Andy Levy wrote:
>>> I have not yet tested this with the command-line client. I hope to
>>> today, but other priorities may get in the way.
>>> One of my users is reporting problems locking a bunch of files on one
>>> of his workstations, so I've been trying to reproduce the issue. I
>>> asked him to upgrade to 1.6.3 and he's still testing. I upgraded
>>> myself to 1.6.3 this morning, and while I can't reproduce his issues
>>> (couldn't with 1.6.2 either), I'm observing a large amount of memory
>>> used and not released.
>>> Steps to reproduce:
>>> 1) I have a WC of 848 PDF files, total size about 1GB (excluding .svn
>>> directories)
>>> 2) Select all PDFs, right-click, TSVn _> Get Lock
>>> 3) Lock Files dialog takes a while to populate, but it's 848 files - I
>>> kind of expect that
>>> 4) Make sure all all are selected and click OK
>>> 5) All files are successfully locked. TortoiseProc.exe shows a Virtual
>>> Size of 649MB, Working Set of 440MB in Sysinternals Process Explorer
>>> (I have 2GB physical RAM)
>>> 6) Click OK. TortoiseProc.exe does NOT disappear from Process Explorer
>>> (I gave it over a minute). Rest of system is bogged down heavily due
>>> to this memory usage.
>>> 7) Terminate TortoiseProc.exe and system behavior returns to normal.
>>> The exact same thing happens when I follow this sequence in unlocking
>>> the files as well.
>> Locking/unlocking is usually done on very few files, so the svn library
>> is optimized for that. Locking/unlocking hundreds of files indicates not
>> a problem with svn but with your workflow (seriously: are you *really*
>> working on all those 848 files at once?).
> I was locking all 848 as an extreme test scenario, to see if I could
> reproduce this individual's issue. He was only locking 150 or so
> files.
> We're rolling out SVN to our whole IT group (about 3 dozen people) of
> which maybe a half-dozen have any software development experience and
> even fewer have source control experience. As a result, a lot of
> people are going to be using "bad" workflows.
> A couple of groups are getting the practice of locking plain-text
> files, despite my repeatedly telling them that it's not needed. Some
> folks are checking out WCs, making a change to a single document, then
> deleting the WC after committing - when they need to make another
> change, they'll just check out all over again.
> There's only so much I can do to "fix" peoples' usage patterns - I'm
> just happy that version control is being used at all.

Well, I still think it's better to educate your people on how to use
Subversion. But anyway: the memory consumption is inside the svn library
so you should report this to the svn mailing list.

Just try
$ svn lock --targets path/to/textfile/containingAllPathsToLock

and check the memory use of the CL client.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-06-24 17:44:40 CEST

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

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