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

Re: Locking design (was Re: svn commit: r9885 - trunk/notes)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-27 07:27:17 CEST

Greg Hudson wrote:

>On Wed, 2004-05-26 at 20:36, C. Michael Pilato wrote:
>
>
>>While I was kinda anti-directory-lock, I fear that by *not*
>>implementing directory locks, we're going to open up a larger can of
>>worms (from a performance and elegance standpoint). As soon as
>>UserOfLargeBinaryfulRepos realizes he can't lock his massive tree of
>>digital video resources, he'll do something worse -- recursively lock
>>each resource in that tree.
>>
>>
>
>I imagine this would only happen with any frequency if we made it easy
>to get a recursive lock.
>
>
That reminds me of a nice "feature" of Visual Studio. Its VC integration
makes it very easy for the user to "check out a project" -- literally
lock all the files mentioned in the project file. Unfortunately it seems
that's fairly common practice: "Oh, I can click that button and it
checks out everything, that's so much simpler than having to check out
every changed file separately..." -- typical developers' laziness
showing one of its eviler sides.

What I'm saying is that even if we, in the command line client or
libsvn_client, don't make it easy to recursively lock files, other tools
will. I think we should take care to not make locking operations (lock,
lookup, unlock) any worse than O(N log N). That's good design, anyway,
but I suspect that what we think of the "borderline" cases of lock usage
will hit us more often than expected.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 07:29:34 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.