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