>
Hello,
Frist of all, thank you for having taken time to reply to my question.
Stefan Küng <tortoisesvn <at> gmail.com> writes:
>
> F.Duarte wrote:
> [...]
> > 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.
Interesting. After reading your answer, I read again the "Chapter 7 : Advanced
Topics - Locking" of the red-bean svn book and found : "Subversion's locking
feature has two main goals: (1. Serializing) 2. *Aiding communication*." That's
what I wanted to do when locking a branch that is being closed, for example.
> > 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?
Yes I am. Notice that the clients are PIV ~3 to 4 GHz w/ 512 to 1024 MB RAM.
> > 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.
Going on with the wvn book with a more interesting thing : "Subversion's locking
feature is currently limited to files only—it's not yet possible to reserve
access to a whole directory tree." So I'm assuming that it is, at least, under
reflection. :)
> > 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.
Yes, that could be a solution ... but for small teams only. Team leaders and
project managers never want to waste time in that kind of tweaking. When they
need a branch to be locked, then "right-click + lock" is better than login in to
the server through ssh, and scripting around because first of all, they dont
(need to) know bah, python and so on : it's not their job. Ant that's why we
love TSVN so much ;)
> 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.
Well... the phylosophy we have here is that the tools shall support the
production process, and not force the production process to be changed.
Anyway, it's my job and I'll try to follow your advice to find a solution based
on a tool that would be more adapted to the situation.
> 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
To conclude : the symptoms effectively seem to be due to an SVN limitation, not
really TSVN (yet), that is dependent on SVN on this point. A workaround can be
the use of the pre-commit hook script.
Thank you for your answer.
Regards.
FD.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Apr 3 11:50:49 2006