On Nov 17, 2004, at 1:55 AM, Ben Collins-Sussman wrote:
>
> On Nov 17, 2004, at 12:10 AM, Robert Hunter wrote:
>>
>> ...
>> Alice sets an attribute "read-only", perhaps with her username as a
>> value.
>> Alice commits revision 11.
>> Alice begins working on the file.
>> Bob accepts a task that requires modifying the same file.
>> Bob runs an update, and receives the new "read-only" attribute.
>> Bob's client sets local filesystem permissions on the file to read
>> only.
>> Bob begins work on the file, but his editor informs him the file is
>> read-only.
>> Alice finishes work on the file.
>> Alice removes the "read-only" attribute.
>> Alice issues commits revision 12.
> You've effectively just described how our upcoming 1.2 'locking'
> feature is going to work, the thing I've been working on for the last
> month or so.
This implies that locking a file will bump the revision number of the
repository, just to change a property. So editing any file with the
svn:must-lock property results in the repository revision being
incremented twice by the time the changes are checked in. Correct? In
fact a lock and unlock with no actual changes to the file would still
bump the revision by 2, right?
Ben, you mention in another message ('Re: Checkout every file as
read-only; make some of them editable with a explicit command.') that
you are working on the locking feature for the BDB back-end. I'm
wondering why the implementation would depend on the back-end at all?
It doesn't seem to matter based on the above description. All the
primitive operations that it is built on (setting and getting
properties) are already available. Obviously I have an oversimplified
view of the problem.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 20:35:25 2004