On Mon, 2005-03-14 at 14:17, Ben Collins-Sussman wrote:
> But there's a whole class of users who will want to lock hundreds (or
> thousands) of files at once, especially those migrating from other VC
> systems. In cmpilato's words: "the moment we decided not to implement
> directory locking is the moment we started having to deal with locking
> thousands of files at once."
(a) I'm not at all convinced that these people exist in significant
numbers.
(b) If these people do exist, I'm not at all convinced that they
wouldn't still exist if we had directory locks. If these hypothetical
people were governed by "if there were a more efficient way of doing it,
I'd do it that way" then they wouldn't be wanting to lock big swaths of
pathnames in the first place.
(c) I'm not personally going to be very sad if such people find that
locking large numbers of files consumes large amounts of resources. In
my mind, mass file locking isn't a very good way of doing work, so if
the system pushes back on people who try it, that's not a terrible
thing.
> Given that svn_repos_fs_(un)lock() will probably -- eventually -- be
> receiving a whole list of locks from the network, cmpilato and I are
> wondering if it makes sense to define the post-(un)lock hooks as taking
> a list of paths *right now*, rather than one path. If somebody decides
> to lock 5000 things at once, it's important to get one email, not 5000
> of them.
That sounds fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 14 20:30:42 2005