I've recently been given the job of taking care of our company's SVN installation, and sure enough one of the repositories stored on it has a problem.

What I see is that if I make a fresh check out of the repository I can make changes to the source code and check it in without a problem, but if I attempt to check in a new binary file (jar or dll) I get an error saying that it cannot set the location pointer to a file. The file is located in the `\db\txn-protorevs' directory. The error goes on to explain that access is denied.

After some investigation I have realized that we're not using just Subversion but the Collabnet Subversion 1.8.13 and Collabnet Subversion Edge for management. These services run on a virtual server in our company network running Windows Server 2008 R2. The repositories themselves are stored not on this server but on our file server (most likely for backup purposes). The file server is also a Windows OS, but I do not know the version. This was all set up and configured before I inherited it, and I'm not certain if I can push through a change to put the services and the repositories on the same server and thus removing the need for a network share, that I've been informed is something of a problem for Subversion.

I have also compared a working repository with the failed repository and it seems that the Filesystem Format is different. The good repository uses FSFS version 3 while the failed repository uses FSFS version 4.

I have administrator rights on the virtual server with the Subversion services, and I can access the network share where the repositories are stored. So running svnadmin is not a problem. Not all repositories on our SVN are affected.

I have attempted the following remedies none of which have worked:

  • Performed a svn cleanup of the working copy.
  • Verified that the service account user has full access to the folders of the repository.
  • Created a temporary repository, but user still had the same problem.
  • Compared access rights between the working repositories and the failed repositories, they are all the same.
  • Verified the SVN client version of the working copy.

What I am trying to figure out is are

  1. How can I recover these repositories so that they can be used again?
  2. How to identify the cause and thus, hopefully, prevent it from happening again?

One thought would have been to perform a dump of the repository, delete it, and create it new and then load the dump file back into it. However, if creating a new repository just for a temporary check in didn't, help I'm not sure if the dump/delete/create/load solution will make it any better.

I'm fairly certain that the FSFS version is not a problem, as I found another FSFS version 4 repository that also does not have the problem with binary files. I've also been looking into the svnserve.conf files but again I cannot find anything that could possibly prevent the checking in of files.

I will update here as I try to find other possible reasons for this behavior.

I have found one workaround but I'm not sure why it works. Apparently when I change the MIME type of a jar file from the default 'application/octet-stream' to 'application/java-archive' I'm able to check-in the jar file without the error. Now if only I knew why that worked but allowing Subversion to use its default MIME type does not.

  • 1. Don't place repositories on network shares, it's always The Bad Idea (tm) 2. Check (possible existing) pre-commit hooks – Lazy Badger Jan 19 '16 at 4:52
  • @lazy sadly 1 is out of my hands that decision was made by our IT department. I will check for 2 though. – JRSofty Jan 19 '16 at 5:12
  • Doesn't appear to be any active pre-commit hooks. – JRSofty Jan 19 '16 at 8:02
  • Did you try to copy this repo in new name and see if it still have problem?, i.e. just checkout files, create new repo (do not delete it old) and commit all file to new repo. It seems some network write issue only on your repo that corrupt the directory node. If you recreate it might fix it. – Sumit Gupta Jan 21 '16 at 7:34
  • We created a new separate repository, but did not export/load a copy of the existing repository. The new repository showed similar problems as the original even in a new state. – JRSofty Jan 21 '16 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.