On Oct 13, 2004, at 8:32 AM, Justin Erenkrantz wrote:
> On Wed, Oct 13, 2004 at 09:09:19AM -0400, Greg Hudson wrote:
>> I think you're missing a fundamental aspect of the locking design.
>> The
>> svn:lock property does not mean the file is locked; it means the file
>> *must be* locked before editing. Locks themselves are not represented
>> by properties. The working copy will learn about contention when it
>> tries to get the lock.
>
> Uh, then, I don't think that's such a good idea. Locks really should
> not have
> to be pre-declared. I should be able to lock any file at any time.
You can. The property causes commit to do the integrity check "is the
file already locked?" But regardless of whether the property is
present or not,
- you can lock the file
- your lock prevents anyone else from locking
I'm not sure about one thing, though: if there's no property, and if
yet there's a lock, then does checkout/update (by someone not the
locker) read-only-ate the file, as is done when the property is set?
As nearly as I can see, locking-ui.txt does not say so (I would assume,
then, the answer to be "no"). But it seems to me that the presence of
an actual lock, regardless of the "svn:must-lock" property, should
force some additional discipline about the file.
In other contexts, we sometimes talk about "advisory" vs. "compulsory"
locks, where "advisory" locks only get in the way of people nice enough
to check for them. Without the enforcement mentioned immediately
above, these seem to be purely advisory locks (for files without the
property, anyway)?
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 02:41:06 2004