Subversion (svn + tortoiseSvn) 提交未锁定文件
我经历过颠覆的奇怪功能。
我们正在使用最新的 1.6 Svn 服务器 Visual svn 和 tortoise svn 1.6.6
我们已经定义了属性 svn:needs-lock 到一个文件，那么如果你从不同的位置复制文件，它会显示本地更改，如果你尝试提交 SVN，它允许你即使您没有获得 LOCK，也要提交。
这对我们来说是一个大问题，请让我们知道如何强制SVN不允许在未获得锁的情况下提交。
谢谢。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Subversion 中的锁定机制不会为您提供一种开箱即用的方法来阻止没有锁定的提交。
您可能（强调可能）能够使用服务器挂钩来处理该问题，但我不确定。也许您应该提出一个新问题，询问如何创建一个颠覆服务器挂钩脚本，该脚本可以防止人们在不首先拥有文件锁的情况下提交更改。
锁定机制只是管理有问题的文件的额外工具，例如内容经常移动的设计文件（因此合并很痛苦），或者对于二进制文件（如果您存储这些文件）。但锁机制并不是开箱即用的，可以防止您在没有锁的情况下进行提交，这只是一种方便，但很容易被绕过。
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.
Subversion 提供锁定功能是为了方便用户管理对其他不可合并文件的并发更改。在 Subversion 中“窃取”锁总是有可能的，因此提交者之间的通信可能仍然是必要的。通过关闭文件的只读属性，您可以获得与所描述的相同的效果。
如果您需要防止用户故意滥用锁定功能，那么 Subversion 可能不是适合您的工具。 Perforce 或 ClearCase 等其他产品的锁定协议要严格得多。
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.
该属性是
svn:needs-lock而不是svn-needs-lock。那可能是你的问题。此外，颠覆不允许您强制锁定任何人。可以使用“--force”选项覆盖锁定。
The property is
svn:needs-locknotsvn-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.
设置 svn:needs-lock 属性没有什么特别的作用：它告诉 Subversion 在签出或更新时在这些文件上设置“只读”标志。
因此，理想情况下，所有设置了 svn:needs-lock 属性的文件都设置了 readonly-flag。
当您获得 svn 锁定时，Subversion 会删除只读标志，以便您可以编辑该文件。
所以你的情况发生的是这样的：
您正在将一个设置了只读标志的文件替换为另一个没有设置此标志的文件。 Windows 不使用替换文件的只读标志。
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.