VisualSVN Error – Revision File lacks Trailing Newline

Question

We have VisualSVN Server 2.1.3 installed on Windows Server 2003 and all client machines are using TortoiseSVN client for commits and other svn operation. Everything was working fine till yesterday.

Yesterday, I committed a revision number 22181 in the night and left the office and this is the last commit which happened since yesterday. When I tried to show log today or tried to update SVN, I got this error:

Revision File Lacks Trailing Newline.

Then I started researching and tried lots of things including the link below which comes as first result in google when I type the error description.

http://www.jamesstroud.com/jamess-miscellaneous-how-tos/os-x-admin/fix-svn-revision-file-lacks-trailing-newline

Though this link says that this error occurs when svn commit size is more than 4GB but the last commit which I did was of hardly 1MB. I still performed the above steps mentioned in the post and after this I was able to do show log into the repository which is a good sign but then I got another error when i tried to commit a file:

Cannot move tempfile.2.tmp to txn-current : the disk structure is corrupted.

Then I reverted the above changes as I took the backup in the beginning and researched more and as per above instruction, it gave me an idea that the problem is with the last revision which I committed yesterday. Then I tried svnadmin.exe using command line and used dump command to make a dump file between revision 1-22180 but but was amazed to see that my server got hanged as maybe dump size which was getting created was more than the size of drive where I was saving the dump file. My motif behind dump was to dump all revisions except last that is 22181 and then create a new repository and load the dump file and that might solve the problem. And then I read that if we specify specific revisions in the dump command, it takes more space than the dump created of whole database. But if take dump of whole database then how do I remove last revision from complete dump file?

If you want to know svnadmin command I ran then here it is: svnadmin.exe dump –r 1-9 F:\svn-repo > C:\Tempdump.dmp

Now I am trying to use verify command after posting this message.

Please help me resolve this problem as I am tired now and tomorrow our staff won't be able to work without svn operations as it is critical. Our SVN repository size is nearly 35GB and I think if I have to use dump command then I will have to attach a USB harddisk in order to save dump file as the server drive which has maximum space is C drive with 48GB space.

I am not sure what the actual solution is. Please help and thank you reading everything.

Thanks

Answer 1

1. The repository is corrupted, do you have a backup to restore from? Restoring the repository from the backup would be the best solution.

   Generally speaking, it makes sense to run svnadmin verify against each repository you have on the storage device to check it for corruption. See svnadmin verify command-line reference.

   Please note that it looks like the storage device (HDD?) got corrupted on the night when you committed revision 22181, I strongly recommend checking it for errors using chkdsk tool and replacing it if needed. See chkdsk tool reference.

2. It's expected that the dump produced by svnadmin dump (using default settings) is larger than the repository on disk. If you want to make the dump of revisions 0-22180 less in size, use "--deltas" option.

   See SVNBook | Repository data migration using svnadmin:

   By default, the dump file will be quite large—much larger than the repository itself. That's because by default every version of every file is expressed as a full text in the dump file. This is the fastest and simplest behavior, and it's nice if you're piping the dump data directly into some other process (such as a compression program, filtering program, or loading process). But if you're creating a dump file for longer-term storage, you'll likely want to save disk space by using the --deltas option. With this option, successive revisions of files will be output as compressed, binary differences—just as file revisions are stored in a repository. This option is slower, but it results in a dump file much closer in size to the original repository.