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.

Answer 2

I found that this issue isn't specific to windows or linux. Here is the background of how I came across this problem. I have an old Linux distro on my development server and i haven't updated it in years, gentoo is a pain to update, so I wanted to make sure that I could migrate my SVN repo to the latest SVN before wiping my server and reinstalling. The old SVN is years old 1.8.11. The new SVN is pretty recent 1.9.5. The difference in versions is 4 years.

So I'll mention how I fixed this under linux.

svnadmin dump <old repo path> > SVN-Repo.dump

Then on the new server with the new SVN server installed, after you create the SVN repository:

mkdir -p <new repo path>
svnadmin create <new repo path>

Then set any permissions you need.

Run the command:

svnadmin load --force-uuid <new repo path> < SVN-Repo.dump

And for me that solves the issue.

In summary, I am skeptical that these errors are caused by corrupt repositories. I think it's more likely that these issues are caused by an svn incompatibility reading the formatting layout of old SVN formats and new.

For example, if i create an new SVN repository on my old version, and then copy it into the new version of SVN, it fails with the same error. Yet it had no time whatsoever to be corrupted. Additionally, for me when i tried to use new SVN on the old SVN repo files, it showed the 2nd last commit (661) as being fine and the last commit (662) as being corrupt. When I removed the last commit (662) and then tried again, it then showed the new last commit (661) as now being corrupt, even though it said that that commit was fine previously. These errors were seen in svnadmin verify. This suggests to me that it's the footer below the revision history that is not readable, and that the repo contents itself is fine.

When we do a dump, for whatever reason, the footer no longer causes any issues. Either because it's not there, or more robustly backward compatible, or because it's ignored.

So if possible - not sure if you can do this under windows, but I suspect you can, take an SVN dump of the old repo, and just import the dump into the new repo. Is it possible that your SVN was updated, and this caused the issue, like it did with mine?