On 4/23/07 7:53 AM, "Mark Phippard" <markphip@gmail.com> wrote:
> On 4/23/07, Thompson, Graeme (AELE)
> <Graeme.Thompson@smiths-aerospace.com> wrote:
>>
>> Hi,
>>
>> The svn:needs-lock property used to prevent commits to files that had
>> not been locked, but with 1.4.3 it is allowing commits to files that are
>> not locked and have the svn:needs-lock property.
>>
>> E.g.
>>
>> Foo has the property need-lock set.
>> Foo is not locked
>> User a changes the file, even though it is read only.
>> User a commits foo
>>
>> With 1.4.3 this completes successfully even though the file is not
>> locked.
>>
>> Around a year ago using a version around 1.2.3 the commit would have
>> been rejected...
>>
>> Is there any way to get the desired behaviour of rejecting the commit
>> when it is not locked using 1.4.3?
>
> I do not believe it ever worked the way you say it did, are you sure
> you did not have a hook script in place? It was never the intention
> of the design to require a lock in order to commit. Locks are a
> communication mechanism only, and the svn:needs-lock property exists
> only as a hint to the user that they should obtain a lock before
> editing a certain file.
>
One exception to that is that you have to get a lock on anything with
needs-lock if you want to delete it. Subversion definitely complains about
that in 1.4.x
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 23 14:57:12 2007