On Mar 14, 2005, at 2:27 PM, John Peacock wrote:
>
> I'm actually with Greg that if the system is slow for people who
> insist on locking everything in sight, it's not such a bad thing
> ("operant conditioning" is the phrase I'd use). I'm just trying to
> make sure we can legitimately withstand the "Your software sucks"
> e-mails from people who scale up locks to their entire repository.
>
In the VSS world, it's the norm for 'owners' of components to keep
their modules permanently locked; it's the default state. These are
the folks who will most likely be wanting/trying to lock whole
directories at a time.
But nevertheless, I think I'm probably "crying wolf" here.
Paraphrasing an IRC conversation:
The all-locks-in-memory thing probably won't be a problem in practice,
as you point out. And once we can lock/unlock a group of paths in a
single network request, things will work pretty well for the VSS
refugees.
I think we're probably on the right path. For now, if someone tries to
lock 5000 things at once and gets frustrated, we can sit back and say,
"sorry, this is a concurrent system, rethink your habits." But someday
in the future, we can remove those obstacles somewhat easily. We've
laid most of the groundwork already in svn 1.2. It's definitely not
worth delaying 1.2 on.
[That said, I'll still make post-(un)lock hooks take a list of paths.
We should warn users not to use these hooks unless they know that
locking will be a "once in a while" thing.]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 14 21:38:57 2005