----- Original Message -----
From: "SteveKing" <steveking@gmx.ch>
To: <dev@tortoisesvn.tigris.org>
Sent: Sunday, June 27, 2004 12:53 AM
Subject: Re: [TSVN] Memory Leak commiting via http...
> illiminable wrote:
>
> > I'm not 100% sure that it was the server change that caused it... i
don't
> > have another svn+ssh server to see what happens now... but that was
really
> > the only thing that changed... before the server moved... it worked
great...
> > then after the move, this happened from the very first time. That's what
> > prompted me to upgrade from 1.0.0 to the latetst version hoping it would
go
> > away.
>
> Ok, you've got to help me here. I just tried to get TSVN to use a lot of
> memory (i.e. I tried commits) with some very big working copies I
> created: 13000 unversioned files, 10000 versioned files, 500 modified
> files, total space used 683MB (sorry, but more is not possible since my
> HD is full).
> And all I got was TortoiseProc using between 15 and 25MB RAM. Even the
> debug build only got to about 35MB RAM.
>
This is the repository http://svn.xiph.org/trunk/oggdsf/ root for my
projects.
> So I need some more information from you:
> - do you show the unversioned files in the commit dialog?
Yes. But there are relatively few... those that are unversioned are
generally new to be commited... everything else not under source control is
filtered by exclude patterns
> - have you set the svn:ignore property for some folders?
I'm not sure what you mean by this... not directly... but i do have folders
that are in my exclude pattern... ie \Debug \Release etc.
> - did you do an 'relocate' of your working copy when the server changed?
No... i couldn't get it to work... i kept getting messages saying "file is
locked" when it definately wasn't... i tried to work aroudn that for a few
days... but nothing
worked... so i checked out the server copy... then copied my local copy over
the top (all the .svn folders were removed from the local copy before doing
this). I had to do this, because prior to the changeover, there was a period
where the server was down and i had lots of local changes that weren't in
the repository.
> - if you have the svn client installed, please do an 'svn st -v' and
> check the memory usage there
OK... did that... never went above 8 megs. And went very fast.
> - if possible, please do a fresh checkout of your working copy and try
again
OK... i did this... and the same symptoms occur whilst checking out...
physical memory use of tortoiseproc peaked at about 500 megs, then dropped
down to sit at around 80megs throughout the rest of the checkout... it also
ate nearly 2Gigs of virtual memory. When the commit finished, the 2Gigs of
virtual memory were released, and also... over 700megs of unnacounted for
physical memory was released... ie even though task manager listed it as
using 80 megs... when the process ended 800 megs of physical memory was
released.
> - what do the statistics tell you in the commit dialog (number of
> unversioned/modified/deleted/... files).
After the checkout i created a small project and added it... it showed 9
files... non-version to be added... which was correct.
The commits now seem to be working a lot faster... though it still uses
about 300 megs of RAM now... but it is faster and doesn't freeze the pc for
10 minutes anymore... so that's an improvement, but it still seems
excessive.
> - do you have a lot of folders in your working copy included with
> svn:externals?
>
Nope.
> I'm really concerned about the memory use you reported, but as long as I
> can't reproduce it I can't do much about it - I wouldn't know where to
> look. Everywhere I looked so far there's no memory leak at all.
>
It is rather strange... it's obviously not a generic bug... otherwise
everyone would notice 800 megs of ram disappearing and there are surely
people with far bigger projects than mine.
Thanks again,
Zen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jun 27 13:47:05 2004