[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checkout every file as read-only; make some of them edita ble with a explicit command.

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2004-11-17 22:48:00 CET

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,
> 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.".

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
> anyway!

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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 22:48:30 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.