Re: Lock/unlock memory leak ?

F.Duarte wrote:

> TSVN version : 1.3.2 build 5840 with (french language pack)
> SVN Server : mod_dav_svn 1.2.0 (r14790) on apache2 on debian linux
>
> I'm experiencing kind of memory leak problems with locking/unlocking with TSVN :
>
> We sometimes need to lock branches that are whole copies of the main one to
> avoid users to commit anything on it for some time. The source tree contains
> around 15000 files in 1200 folders tacking around 350 MB.
>
> Clicking "Get lock..." on the main directory allows us to lock every file in it.

The locking feature isn't made for this. It is there for locking files
you're currently working on. So you're basically putting a real stress
on Subversion here by 'misusing' the feature.

> Symptoms :
> The lock process takes more than one hour and a half and exhaust RAM and virtual
> memory. Same for the unlock porcess that takes more than TWO houres, eats more
> than 260 MB of RAM and more than 1.2 GB of virtual memory (not far away from
> preventing the user to use its PC during this time).

I guess you're talking here about the client and not the server machine?

> I wonder if anyone has this same kind of problem of if this behaviour can be
> reproduced somewhere to confirm that problem and finaly get it corrected.

I really doubt that it even can be corrected. It would require for the
whole feature (locking) to be rewritten.

> A connex problem is that when such a branch gets finally locked, the server
> seems to slow down when exploring the repositories with the repo-browser,
> especially on branches that handles such locked sub-branches. But I should ask
> this to the SVN mailing list as it seems to be a server side problem.

Also the problem on the client machine is a Subversion 'problem'. But
basically, the problem is on what you use locking for.

In your case, you basically want to prevent commits to a whole branch.
So you should use a pre-commit hook or the mod_autz_svn module for that.

All I want to say here is that you should use the right tool for the
right problem. Then you won't have those problems you've described.

As for TSVN, there's nothing we can do here. The svn_client_lock() and
svn_client_unlock() API's don't take a 'recursive' parameter - every
single file has to be locked/unlocked separately. That's also true for
the server. And that's why you see those problems.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org