On Nov 17, 2004, at 1:34 PM, Scott Palmer wrote:
>
> 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?
Let me clarify.
I'm not talking about the 'svn:needs-lock' property getting constantly
added and removed or changed. It's attached to the file *once*, just
like 'svn:eol-style' or 'svn:keywords'. And it stays attached,
forever.
When the svn client sees that property, it automatically makes the file
'read-only', all the time. Only by running 'svn lock' does the file
become read-write, and then after the lock is released it goes back to
read-only again. The property isn't changing at all. The property
merely exists as a signal to the svn client, telling the client that
this file "should be uneditable, unless your user locks it.".
>
> 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.
>
Locks are a feature of the filesystem itself: libsvn_fs.so, and
svn_fs.h. The filesystem API is used to create and destroy them, and
they are enforced by the filesystem.
If we implemented a locking system that only exited (or were enforced)
by svn clients, then any program could easily circumvent them, or even
worse -- accidentally ignore them. You lock a file with svn 1.1
client. Then an svn 1.0 client comes along and changes the file
anyway! Whoops. Also remember that generic DAV clients (which know
nothing of Subversion) expect the server to able to lock/unlock things.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 21:53:50 2004