On Nov 17, 2004, at 3:53 PM, Ben Collins-Sussman wrote:
> 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,
> 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
Ah, where is the information about "already locked by xxxxxx" stored?
>> Obviously I have an oversimplified view of the problem.
Told ya :)
> 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.
Duh, of course... I forgot entirely about enforcement issues. Though,
it is really my ignorance of how subversion is working under the
> 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
Do clients need to know which filesystem is being used? I guess the
filesystem API fits in at a different level than I was thinking.
Since 'file:' URLs can be used to access the repository... which
essentially means the "client" is the "server"... so what about a svn
1.0 client using a 'file:' URL on a repository that was created with
1.2 and has 'svn:needs-lock' set on some files? Will that case be
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 17 22:48:30 2004