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

Re: another idea for directory locking.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-10-21 00:25:15 CEST

On Oct 20, 2004, at 5:08 PM, Greg Hudson wrote:

> On Wed, 2004-10-20 at 16:28, Ben Collins-Sussman wrote:
>> The counterargument, though, is that users are going to want to lock
>> whole trees no matter what.
> I don't think they will. I think we should implement file locking and,
> with that variable controlled for, wait and see how many users ask for
> directory locking.
> It's not that I'm "only interested" in solving one specific problem.
> I'm not really interested in locking at all, myself. But I've only
> seen
> a user demand for one specific problem, and I feel like we're trying to
> solve another problem, which essentially no one cares about, merely
> because we see it as low-hanging fruit once we have file locking. But
> it's not really fruit and it's not really low-hanging.

Stop it now. All of you are eroding my will to persue this fruit. :-)

Seriously, maybe you and Julian are right: is there great utility in
trying to perpetuate the illusion of a recursive lock?

Do users actually need directory locks? Maybe it would just be enough
to give them a UI that allows them to lock a large number of files in
one step?

Also, maybe Julian Reschke can tell us if there are any prominent DAV
clients out there which desperately depend on directory locking. Most
of our motivation for writing this feature is to serialize access to
unmergeable files; but there's still some motivation to try and open
the way to a reasonably complete and interoperable autoversioning
feature. How important is directory locking to WebFolders, MSWord,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 00:25:44 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.