[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: Andy Levy <andy.levy_at_gmail.com>
Date: Wed, 24 Jun 2009 11:49:40 -0400

On Wed, Jun 24, 2009 at 11:44, Stefan Küng<tortoisesvn_at_gmail.com> wrote:
> 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.

I don't disagree, but I'm not in a position where I can force people
to see things my way. All I can do is nag them every time I see them
doing bad things.

> 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.

Confirmed with 1.6.2 (haven't upgraded to 1.6.3 yet), BUT there is a
major difference here - when the CL client finishes the locks, it
releases the memory and terminates within 2 seconds. When I use TSVN,
TortoiseProc.exe remains in the process list after I close the window
and the memory is not released.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2364991

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-06-24 17:49:47 CEST

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