Subversion (svn + tortoiseSvn) commits an unblocked file

Question

I experienced the strange functionality of subversion.

We use the latest svn server version 1.6 svn and svn 1.6.6 turtle

We defined the svn: require-lock property for the file, and then if you copy the file from another place, it shows a local change, if you try to transfer SVN, it allows you to make transactions even if you did not receive LOCK.

This is a big problem for us, please tell us how to get SVN to not commit without getting a lock.

Thanks.

Answer 1

The locking mechanism in Subversion will not give you, out of the box, a way to prevent committing without locking in the first place.

You can, by focusing on capabilities, handle this with server interceptors, but I'm not sure. Perhaps you should ask a new question where you ask how to create a subversion script server hook that prevents people from making changes if they don't first have a file lock.

The locking mechanism is just an additional tool for managing problematic files, such as designer files, where content moves around a large number (so merging is a pain) or for binary files if you store them. But the locking mechanism is not out of the box, to prevent you from committing without locking, it's just a convenience, but it can be easily circumvented.

Answer 2

Subversion provides locking functionality as a convenience to help users manage concurrent changes to otherwise uncultivated files. You can always “steal” a lock in Subversion, so communication between committers may be necessary. You can get the same effect as you by disabling the read-only attribute in the file.

If you need to protect against users intentionally abusing the lock feature, then Subversion might not be right for you. Other products, such as Perforce or ClearCase, are much more stringent with blocking protocols.

Answer 3

svn:needs-lock property svn:needs-lock not svn-needs-lock . This may be your problem.

Also, subversive activity does not allow forcibly blocking anyone. Locks can be overridden with the `--force` parameter.

Answer 4

Setting the svn: needs-lock property does nothing special: it tells Subversion to set the read-only flag in these files when checking or updating.

Ideally, all files with the svn: needs-lock property set have the readonly flag set. When you get an svn lock, Subversion removes the readonly flag so you can edit the file.

So what happens in your situation: you are replacing a file with the readonly flag set by another file that does not have this flag. And Windows does not use the readonly flag of the replaced file.