I have experienced strange functionality of subversion.
We are using latest 1.6 Svn server visual svn and tortoise svn 1.6.6
We have defined property svn:needs-lock to a file, then if you copy over file from different location it shows local change if you try to commit SVN it allows you to Commit even if you didn't obtain the LOCK.
This is a big problem for us, please let us know how to force SVN not to allow commits without obtaining the lock.
Thanks.
Subversion provides the locking functionality as a convenience to help users manage concurrent changes to otherwise unmergeable files. It is always possible to "steal" a lock in Subversion, so communication between committers may still be necessary. You can get the same effect as you describe by turning off the read-only attribute on a file.
If you need to protect against users deliberately misusing the locking feature, then perhaps Subversion is not the right tool for you. Other products such as Perforce or ClearCase are much more stringent with the locking protocols.
The property is svn:needs-lock not svn-needs-lock. That could be your problem.
Also subversion doesn't allow you to force locks on anyone. Locks can be overridden using the `--force`` option.
The lock mechanism in Subversion will not give you, out of the box, a way to prevent commits without a lock first.
You might, emphasis on might, be able to handle that with server hooks, but I'm unsure. Perhaps you should ask a new question where you ask how to create a subversion server hook script that prevents people from committing changes if they don't own the lock on the file first.
The lock mechanism is just a extra tool to manage problematic files, like designer files where the content gets moved around a lot (so merging is a pain), or for binary files, if you store those. But the lock mechanism is not, out of the box, there to prevent you from committing without a lock, it's just a convenience, but can easily be circumvented.
Setting the svn:needs-lock property does nothing special: it tells Subversion to set the 'read only' flag on those files when checking out or updating.
So ideally, all files with the svn:needs-lock property set have the readonly-flag set. When you get the svn lock, Subversion removes the readonly flag so you can edit the file.
So what's happening in your situation is this: you're replacing a file which has the readonly flag set with another file which does not have this flag set. And Windows doesn't use the readonly flag of the replaced file.