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

Re: svn commit: r14031 - trunk/subversion/clients/cmdline

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2005-04-10 02:44:51 CEST

On Apr 9, 2005, at 10:06 AM, Ben Collins-Sussman wrote:
> On Apr 9, 2005, at 8:52 AM, Philip Martin wrote:
>> Norbert Unterberg <nepo@gmx.net> writes:
>>> Peter N. Lundblad schrieb:
>>>>> svn:needs-lock - If present, the file must be locked when it is
>>>>> committed.
>>>> Not true. svn:needs-lock is a client-side thing. It communicates to
>>>> your
>>>> fellow collegues that this file must be locked. The repository
>>>> doesn't
>>>> care.
>>> Quote from
>>> http://svn.collab.net/repos/svn/trunk/notes/locking/locking-ui.txt
>>> II. New Client Behaviors
>>> B. The "svn:needs-lock" property
>>> 1. Property as enforcement system
>>> The presence of the "svn:needs-lock" property on a file
>>> means
>>> that concurrency is disabled for the file and a user *must*
>>> obtain a lock on that file before committing changes to it.
>>> The server rejects any commit which modifies this file
>>> unless
>>> the user has a lock on the file. [...]
>>> So who is correct?
>> Ha! Well that explains why I thought it was mandatory rather than
>> advisory. I was wondering where I got that idea :)
> Whoops, that paragraph is out of date, sorry. Somewhere along the
> line we decided not to have the server enforce that behavior.

Crap.. I wish I knew that before so I could whine about it. I now
consider locking to be 100% broken by design. What good is locking if
it isn't enforced? This seems as logical as making the client decide
who has write access to a repository.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 10 02:45:33 2005

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