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

Re: Recursive lock and unlock commands

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sun, 11 May 2014 18:32:48 +0000

While, It might help this specific user to implement this… I'm wondering what this user is really trying to accomplish, and if there are perhaps better ways to do this?


Adding thousands of locks is going to introduce many scalability issues.


I wouldn't be surprised if this user would really want something like:

Client updatable authz or


Recursive directory locks



If all you have is a hammer, you want to solve all your problems with nails…


But there are so many other solutions. And personally I don’t think exclusive per file locks are such a good generic solution for most bigger problems.


Both the ASF and Google code forbid file locks on their repositories under certain circumstances for good reasons and we didn't solve mirroring locks to slaves yet.


Bert




Sent from Windows Mail





From: Julian Foad
Sent: ‎Wednesday‎, ‎May‎ ‎7‎, ‎2014 ‎11‎:‎29‎ ‎PM
To: dev_at_subversion.apache.org





A customer asked if we could provide a recursive "svn unlock" command -- presently they script it. Someone else asked in 2009 -- <http://svn.haxx.se/users/archive-2009-08/0354.shtml>.

It sounds totally reasonable to me. In fact it sounds like an oversight that we didn't offer this originally.

Of
 course we'd want to implement this for URLs and for WC paths, and for
all the 'depth' variants not just 'infinite', for consistency.

I would propose that

  "svn lock/unlock --depth=D URL" means lock/unlock all existing files (not directories) under URL down to depth D.

 
 "svn lock/unlock --depth=D WC-PATH" means lock/unlock all the versioned
 files (not directories) in the WC under WC_PATH up to depth D. With
regard to recursing into externals, switched paths, etc., this should
use the same recursion rules as some other command; not sure which
exactly.

The main performance considerations would seem to be:
Philip recently implemented batching of multiple lock/unlock requests in
 one network command, which should make multiple lock/unlock requests
much better than before; it would still be slow with old servers; but it
 won't be slower than the wrapper script approach.

Anything I've missed?

- Julian

--

Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise
<http://www.wandisco.com/training/webinars>
Received on 2014-05-11 20:42:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.