我遇到了Apache Subversion存储库的问题，我正在寻找最佳解决方案：
我无法提交Subversion存储库而且我收到错误：
svn：E720002：提交失败（详情如下）：svn：E720002：无法打开 文件'C：\ Repositories \ myproject \ db \ txn-current'：The 系统找不到指定的文件。
如果我创建一个空的txn-current文件，如果在提交时会收到另一个错误：
svn：E070014：提交失败（详情如下）：svn：E070014：无法读取 文件'C：\ Repositories \ myproject \ db \ txn-current'：结束 找到的文件
注意：让我们假设我没有存储库的备份，所以我必须手动解决问题。
StackOverflow上已经讨论过相同的行为：svn commit problem, Cannot read 'd:\UC\db\txn-current': End of file found。但是我怀疑那里的答案确实有用：
我不认为手动创建\db\txn-current并在其中放置0（或任何其他整数）是一个很好的解决方案。我想这可能会在不久的将来导致一些意想不到的行为，
svnadmin recover和/或svnadmin verify不会创建和/或填充txn-current。在这种情况下，这些命令无能为力。
根据FSFS description \db\txn-current文件包含下一个交易密钥编号。如果我把一些整数放到文件然后我可以提交，整数将增加1。
然而，看起来像放一些不相关的整数会破坏我的回购中的某些东西，我不希望这种情况发生。
“txn-current”文件是一个包含单行文本的文件 仅包含base-36编号。当前值将用于 下一个事务名称，以及事务的修订号 是根据。此序列号确保事务名称 即使交易中止和新交易，也不会重复使用 基于相同的修订开始。 FSFS唯一的操作 对此文件执行“get and increment”; “txn-current-lock” 文件在此操作期间被锁定。
如何正确解决\db\txn-current问题？我应该在文件中放入什么整数？还有其他方法可以解决这个问题吗？
编辑：
db/current文件解决相同问题（不存在或为空）？答案 0 :(得分：3)
我有类似的问题。为了解决，我编辑了'txn-current'文件，把一些大数字说成xxxxx。与此同时，我不得不在'db \ transactions'文件夹中编辑另一个名为'current'的文件。我删除了此文件中的所有内容，只添加了一个输入并关闭了此文件。
答案 1 :(得分：2)
在FSFS txn-current中保存下一个交易ID。提交后存储在修订版本中的事务ID。所以txn-current中的puttign真的很大。应该没问题。
另一个解决方案是svnadmin dump存储库，然后svnadmin load将其存储到新存储库。
更新：txn-current文件损坏问题已在r1483781中进行了调查和修复。
修复版可在Subversion 1.7.10及更高版本中使用。
答案 2 :(得分：2)
我收到的错误是“无法读取'D：\ SVNROOT \ UC \ db \ txn-current'：找到文件结尾” 在进一步探测时，我们意识到在一些服务器操作系统升级活动之后，db文件夹中的“当前”文件是空的。 我们从revs文件夹中找到了最新版本号，并将该号码添加到“当前”文件中
它仍然不起作用然后我们发现这个article指定你必须输入修订号，然后再输入“
这可以解决错误！
答案 3 :(得分：2)
我遇到了类似的问题，在提交过程中发生了电源故障。我尝试修改“当前”文件，但它没有用。
我备份了存储库，然后删除了“当前”文件，并在存储库上运行了“svnadmin verify”。此后，我收到以下错误：
“格式错误的文件svn：序列化哈希缺少终结符”
然后我进行了存储库转储，删除了旧存储库，重新创建了存储库并导入了转储文件。
此后一切顺利。完整的存储库和历史记录仍然存在。
答案 4 :(得分：1)
我做了：
svnadmin verify /mnt/repos/
svnadmin recover /mnt/repos/
仍然有错误......
svn: E000002: Übertragen schlug fehl (Details folgen):
svn: E000002: Kann Datei »/mnt/repos/db/txn-current« nicht öffnen: Datei oder Verzeichnis nicht gefunden
然后我创建了空文件：/mnt/repos/db/txn-current
然后svn ci再次工作
如果您不想等待：
svnadmin verify -r 997:HEAD <path>
更快。交换997版本号，小于错误修订版
答案 5 :(得分：0)
就我而言。设置SVN的VirtualMachine的空间已满。 所以清理空间