没有匹配的锁定令牌答案

【问题标题】：No matching lock-token没有匹配的锁定令牌
【发布时间】：2015-03-28 03:12:23
【问题描述】：

提交完成后，svn status 显示锁定令牌为否更长的时间出现在工作副本中。这是 svn 的标准行为提交——它搜索工作副本（或目标列表，如果您提供这样的列表）用于本地修改并将所有锁定令牌发送给它在这次步行到服务器作为提交的一部分交易。提交后顺利完成，所有的提到的存储库锁被释放——即使是在那些没有承诺。这是为了劝阻用户不要马虎关于锁定或持有锁太久了。

在尝试确保此功能正常工作时，我在尝试提交已锁定在我的工作副本中的文件更改时不断收到此消息：

svn: Cannot verify lock on path '/test/test'; no matching lock-token available

现在，我已经在 Windows 上的两个不同工作副本中测试了这个场景，在 RHEL 上测试了一次，每次都出现相同的错误，重新签出并且没有事先锁定文件。如果我解锁文件然后提交，没问题，提交就会发生。如果我使用 svn:needs-lock 属性，如果在解锁文件之前尝试提交，则会出现同样的错误。

我很确定错误不是发生在客户端，而是发生在服务器端。我认为可能是客户端没有将本地授权令牌传递回 Subversion 服务器。但是，我已经用三个不同的客户端（2 CLI 和 Subclipse）进行了尝试。因为它在三个不同的客户端上失败了，所以我觉得客户端正在将本地授权令牌传递回服务器。所以我很确定服务器是我需要解决这个问题的地方，但是在哪里呢？

【问题讨论】：

澄清一下，svn lock test/test ; echo "foo" >> test/test ; svn ci -m 'check-in while holding lock' test/test 失败了？
在 Unix 和 Windows 上（对平台进行了一些修改），该命令失败并显示 'svn: Cannot verify lock on path '/test/test';两个系统上都没有可用的匹配锁定令牌。

标签： svn

【解决方案1】：

我遇到了同样的问题：

svn: E160037: Commit failed (details follow):
svn: E160037: Cannot verify lock on path '/QHG3/trunk/kernel/Activator.cpp'; no matching lock-token available

我能够通过“偷”锁来解决这个问题：

svn lock --force AltMoverPop.cpp

【讨论】：

你们都用什么版本的Subversion？我相信在发布这篇文章时，如果有帮助的话，我正在使用 Subversion 1.6.x。
与远程团队合作并遇到此问题。偷锁对我有用。
应该是公认的答案，不需要客户端，只是一个简单的命令！

【解决方案2】：

好吧，我对你的问题做了一些环顾四周，发现 this.

它说的是检查文件是否是只读的，如果是，SVN 认为文件被锁定并且没有匹配的锁定令牌可用（因为它实际上并没有被锁定）。因此，如果它们是只读的，请尝试将它们设置为可写。

如果这不起作用，请查看here。

【讨论】：

谢谢，我在自己对这个问题的研究中发现了相同的链接。抱歉，当提交发生时，文件未设置为只读，并且在存在锁时工作副本没有被销毁和重新创建。我敢打赌，问题不在于您提供的两个链接所建议的客户端，而在于服务器端。

【解决方案3】：

哦，伙计..我在支柱上搜索帖子。对我来说，问题是相同的“锁不工作，”

右键-->获取锁-->勾选“窃取锁”。修改文件，并签入。暂时是为我做的

【讨论】：

【解决方案4】：

可能服务器上的存储库已损坏。在服务器上使用svnadmin 转储存储库，将其加载到临时存储库中的另一台计算机上，并尝试对临时存储库执行相同的操作。

如果这样可以解决错误，请备份旧存储库并将其替换为临时存储库。

【讨论】：

我已经使用 svnadmin verify 完成了该检查，这基本上是一个没有输出的 svnadmin 转储。存储库是健全的。我们也有多个 repos，并且我们在所有这些上都有相同的行为。谢谢！
您检查服务器上的磁盘空间了吗？文件权限如何？而且我仍然建议在另一台机器上加载 repo（你可以在你的客户端上这样做）。如果这行得通，你会知道更多。
磁盘空间还可以。文件权限，值得怀疑，因为我没有设置这个服务器，而那些做过的人，真的不知道 Subversion。我正在修复很多小东西，所以权限可能是可能的，但由于服务器已被完全锁定，因此无法验证。基本上，我没有 chown 权限。我会在另一台机器上加载 repo 并对其进行测试，但他们没有足够大的资源来尝试这样做，更不用说足够的磁盘空间来完成转储而不添加额外的资源，这暂时不会发生。
在这种情况下，获取 Subversion 的源代码并在其中搜索错误消息。这可能会给你一个线索，是哪个条件触发了错误。