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

Re: Locking functional spec: read-only WC

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-10-13 20:35:58 CEST

On Oct 13, 2004, at 12:01 PM, John Peacock wrote:

> Ben Collins-Sussman wrote:
>> Suppose somebody tries to commit a hijacked file that has the
>> 'svn:must-lock' property attached. My instinct is that they get an
>> error saying "get a lock first!", regardless of whether someone has
>> already locked the file or not. This teaches the user to stop
>> hijacking.
> Perhaps the conceptual thing I am stuck on is that file/directory
> locking can happen without the svn:lock property being set. Here, the
> WC has no notion that the file is locked until commit time, which
> violates the goal in I.A.2. to provide a communication mechanism to
> prevent needless editing which will be blocked by locks.

Correct. If you choose to lock an ordinary mergable file, like a C
file, then presumably there's no way I'd know about it, other than

    - running 'svn st -u'
    - seeing an email from the post-lock hook script

> I can see the utility for non-mergeable files of forcing the lock to
> be obtained in advance of the commit (and I've reread the Hijack
> section again now ;). But if we are to permit locking of files
> without setting the flag, how is that going to facilitate
> communicating that the file is locked now?

It's not important that locking communication be "good" in the case of
mergeable files. Why? Because the file is mergable. Suppose you lock
foo.c and I'm unaware of this. Then I edit foo.c and my commit fails.
My work is 'wasted'. I run 'svn up', merge things, then eventually
commit after you release the lock.

The whole point of the 'svn:needs-lock'/read-only communication system
is that it prevents people from writing *unmergeable* changes.

So I don't feel like there's a problem that needs solving here.

> What we really need is not a flag but a tri-state:
> 1) this file must be locked before editing (binary/non-mergeable)
> 2) this file can be locked (mergeable files)
> 3) this file cannot be locked
> then this would fit all of our needs. People who don't want to permit
> locking set #3 at the root of the repository (and all files would
> inherit it). The normal state would be #2 (matching the current
> behavior, mostly), and the exceptional case would be #1.

Oy, inherited properties?? Now you've spun us off into a whole new
dimension of complexity!

Why is case #3 needed at all? If an admin is morally opposed to
locking of any kind, then just set the 'pre-lock' hook script to always
return failure.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 20:36:23 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.