Re: Locking functional spec: read-only WC

Ben Collins-Sussman wrote:

> There are two scenarios here:
>
> 1. An admin wisely puts an 'svn:lock' property on an image file.
>
> This means that the file is read-only most of the time, and users
> *must* obtain a lock before they can start editing; this prevents
> people from wasting time on unmergeable changes.

Except that by relying on the filesystem r/w attribute, we cannot
completely prevent users from flipping that bit without using a
Subversion client to obtain a lock. Subversion does not provide an IDE
and we don't have the luxury of hooks into the editor to mediate all
access to version controlled files.

The lock is still only truly enforced when trying to commit, so I think
the client needs to behave appropriately when attempting to commit a
file with svn:lock set without having previously obtained a lock. What
I'd prefer to what's in locking-ui.txt:

a) the file is not already locked, so a lock is created, the file
committed, and the lock released (I'd also like to see it throw a
warning here);

b) alternatively, even if the file is not already locked, the server
could require a lock to be obtained as an independent step before
permitting the commit (I would suggest this be an administrative option);

c) the file _is_ locked, so the commit fails with an appropriate error
message - "You DOPE! You need to get a lock first!" ;)

Case a) would work like the current non-locking behavior in a completely
transparent fashion and I'd personally use that in preference to b).
Perhaps the value of svn:lock could determine which mode:

svn:lock = 0 or null - lock must be proactively present before any
commit on this file is possible

svn:lock = 1 - existing lock will block commits, but otherwise an atomic
commit will be lock => commit => unlock

svn:lock = 2 - signed note from your mom required for commit ;)

>
> 2. Justin's team is collaborating on a mergeable text file.
>
> This file would have so such 'svn:lock' property or resultant
> read-only attribute.

I think you mean "no such" here.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org