我最近被赋予了负责我们公司的 SVN 安装的工作，果然其中存储的一个存储库出现了问题。
我发现，如果我重新检查存储库，我可以对源代码进行更改并毫无问题地签入，但如果我尝试签入新的二进制文件（jar 或 dll），我会收到一条错误消息，提示无法将位置指针设置为文件。该文件位于“\db\txn-protorevs”目录中。该错误继续解释访问被拒绝。
经过一番调查，我意识到我们不仅使用 Subversion，还使用 Collabnet Subversion 1.8.13 和 Collabnet Subversion Edge 进行管理。这些服务在我们公司网络中运行 Windows Server 2008 R2 的虚拟服务器上运行。存储库本身不存储在此服务器上，而是存储在我们的文件服务器上（很可能是为了备份目的）。文件服务器也是 Windows 操作系统，但我不知道版本。这一切都是在我继承它之前设置和配置的，我不确定我是否可以推动一项变更，将服务和存储库放在同一台服务器上，从而消除对网络共享的需求，据我所知，这对 Subversion 来说是一个问题。
我还比较了正常工作的存储库和出现故障的存储库，发现文件系统格式似乎有所不同。正常工作的存储库使用 FSFS 版本 3，而出现故障的存储库使用 FSFS 版本 4。
我在具有 Subversion 服务的虚拟服务器上拥有管理员权限，并且可以访问存储存储库的网络共享。因此运行svnadmin不是问题。我们 SVN 上并非所有存储库都受到影响。
我尝试过以下补救措施，但均不起作用：
- 执行了
svn cleanup工作复制。 - 已验证服务帐户用户是否具有存储库文件夹的完全访问权限。
- 创建了一个临时存储库，但用户仍然遇到同样的问题。
- 比较工作存储库和失败存储库之间的访问权限，它们都是相同的。
- 验证工作副本的 SVN 客户端版本。
我想弄清楚的是
- 我如何恢复这些存储库以便再次使用它们？
- 如何找出原因并尽量防止其再次发生？
一个想法是执行存储库转储，删除它，然后创建新的存储库，然后将转储文件重新加载到其中。但是，如果只是为了临时签入而创建新的存储库没有帮助，我不确定转储/删除/创建/加载解决方案是否会使情况变得更好。
我相当确定 FSFS 版本没有问题，因为我发现另一个 FSFS 版本 4 存储库也没有二进制文件问题。我也一直在研究 svnserve.conf 文件，但我还是找不到任何可能阻止签入文件的东西。
当我尝试寻找此行为的其他可能原因时，我将在这里更新。
我找到了一种解决方法，但我不知道它为什么有效。显然，当我将 jar 文件的 MIME 类型从默认的“application/octet-stream”更改为“application/java-archive”时，我能够签入 jar 文件而不会出现错误。现在，如果我知道为什么这样做有效，但允许 Subversion 使用其默认 MIME 类型却不行。