svnsvnadminsvn-repositoryfsfssvn-administraton

Empty or non-existent '/db/txn-current' in a Subversion repository


I've encountered an issue with Apache Subversion repository and I'm looking for the best solution:

I can't commit to a Subversion repository and I'm getting the error:

svn: E720002: Commit failed (details follow): svn: E720002: Can't open file 'C:\Repositories\myproject\db\txn-current': The system cannot find the file specified.

If I create an empty txn-current file if will get another error on commit:

svn: E070014: Commit failed (details follow): svn: E070014: Can't read file 'C:\Repositories\myproject\db\txn-current': End of file found

NOTE: Let's imagine that I don't have a backup of a repository so I have to fix the issue manually.

The same behavior has been already discussed on StackOverflow: svn commit problem, Cannot read 'd:\UC\db\txn-current': End of file found. However I doubt that answers there are really helpful:

According to the FSFS description \db\txn-current file contains the next transaction key number. If I put some integer to the file then I can commit and the integer will increase by 1.

However looks like putting some irrelevant integer can break something in my repo and I don't want this to happen.

The "txn-current" file is a file with a single line of text that contains only a base-36 number. The current value will be used in the next transaction name, along with the revision number the transaction is based on. This sequence number ensures that transaction names are not reused, even if the transaction is aborted and a new transaction based on the same revision is begun. The only operation that FSFS performs on this file is "get and increment"; the "txn-current-lock" file is locked during this operation.

What should I do to fix the \db\txn-current issue properly? What integer should I put into the file? Is there any other way to solve this?

EDIT:


Solution

  • In FSFS txn-current holds next transaction id. Transaction ID stored in revision itself after committing. So puttign really big number in txn-current should be fine.

    Another solution would be to svnadmin dump repository and then svnadmin load it to fresh repository.

    UPDATE: The issue with txn-current file corruption was investigated and in fixed in r1483781.

    Fix is available in Subversion 1.7.10 and later.