How can I fix the SVN import line termination error?

Question

I need to import a huge SVN repository, which I need to transfer from one server to another. Therefore, I exported it from the old server:

svnadmin dump . > archive.svn 

and import it into a new one:

 svnadmin load . < archive.svn 

In the middle of the import process, I got this error:

 Cannot accept non-LF line endings in 'svn:ignore' property 

How can i fix this? I have full control over both servers.

Answer 1

Have you changed the server version? This is a known issue in version 1.6 and causes problems when upgrading from 1.4 or 1.5.

Subversion 1.6 no longer accepts carriage returns (^ M) in property files. You will need to fix line breaks in svn: ignore files or see if it is easier.

Alternatively, you can go Subversion 1.7 or use uberSVN .

Answer 2

You have 2 options, edit the source or disable profile verification.

Source fix (svn: log and svn: ignore):

 sed -e '/^svn:log$/,/^K / s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' archive.svn > repaired-archive.svn svnadmin load . < repaired-archive.svn 

Where ^ M is the control character, i.e. 0D in hexadecimal format. To do this, use ^ V ^ M ( control V control M ) instead of ^ M (circumflex M or control M)

Disabling validation validation:

 svnadmin load --bypass-prop-validation . < archive.svn 

Answer 3

The first answer @ ventura10 sounded good, but didn't work for me. The sed command changed some versions with a version outside the properties section, which led to md5 inconsistencies when loading the dump.

Since my repository has no binary content properties, I changed the sed command to fix all the properties, not just svn:log and svn:ignore . I was also sure that not one version file contained a line starting with Prop-content-length: Otherwise, I would have an error loading the dump.

 sed -e '/^Prop-content-length: /,/^PROPS-END$/ s/^M/ /' svn.dump > svn.dump.repaired 

It is important to replace ^M with [blank] , since the size of the property value should not change.

@ Ventura10 remains valid:

^ M is the control character, which means 0D in hexadecimal. To use it ^ V ^ M (control V control M) instead of ^ M (circumflex M or control M)

It's hard to believe that upgrading an existing repository from svn 1.4 to svn 1.7 makes this step invisible, but I have not found another way to get rid of carriage returns that are no longer accepted with svn 1.6.

Answer 4

With a little gymnastics, you can get around this using svnsync , which has the ability to fix EOL. Say your repository is dumped in archive.svn .

First create a repository to download the repo back, ignoring EOL issues:

 svnadmin create repo svnadmin load repo < archive.svn --bypass-prop-validation 

Now create a new repository to copy:

 svnadmin create repo-fixed 

svnsync requires some pre-commit binding, even if you don't use it, so just use your editor to create an empty one in repo-fixed/hooks/pre-revprop-change :

 #!/bin/sh exit 0 

Initialize the destination repository for svnsync :

 svnsync init file:///path/to/repo-fixed file:///path/to/repo 

Now copy the entire repository:

 svnsync sync file:///path/to/repo-fixed 

Phew! svnsync will even give you good news: NOTE: Normalized svn:* properties to LF line endings (Why the Subversion team did not update svnadmin to do the same normalization is a mystery to me.)

After that, dump the new repository:

 svnadmin dump repo-fixed > archive-fixed.svn 

You now have archive-fixed.svn , which should be identical to archive.svn , except that EOLs have been fixed as needed.

(Optional) Now you can delete the temporary repository that you used for svnsync :

 rm -rf repo-fixed 

Refresh . It turns out that if you download this new dump, your Subversion client will receive an error message: Repository UUID does not match expected UUID . You will need to use svnadmin setuuid ... to change the UUID to what it used .

(This post is the culmination of many fragments and partial solutions that I found on the Internet. Thanks to all the people who knew more than me, I just put it all together.)

See also:

• Copy subversion repositories with history using svnsync
• stack overflow
• https://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

Answer 5

I ran into this error when updating 1.6 repo to 1.8. I found several “fixes” on the net.

"-bypass-prop-validation I didn’t like because it postpones the problem, the next time you need to restore the repo, you will get into the same test.

I found a bash script to scroll through the revisions, getting the comments and installing them again, but that didn't work.

Improving the ventura10 solution did the job. Due to the size of the dump, I ended up using a single command to remove unwanted characters when restoring a dump

  sed -e '/^svn:log$/,/^K / s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' /path/to/svn.dump | svnadmin load /path/to/repo 

NOTE:

Where ^ M is the control character, that is, 0D in hexadecimal. To use it ^ V ^ M (control V control M) instead of ^ M (circumflex M or control M)

Answer 6

Use svndumptool :

 svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired 

The @tangens solution works for me too, but it is not perfect as I get an extra space as a replacement for carriage return characters. However, I checked that svn: ignore still works with this extra space, but I did not test other SVN properties.

The downside of using svndumptool is that it can only work with one svn property at a time, which is time consuming if your dump files are large.

---

Some results

You may be interested to know why @tangens did not replace ^ M with an empty character. If you try to replace it with a null character, you will get this error:

 svnadmin: E140001: Dumpstream data appears to be malformed 

The dump file saves the Prop-content-length property, which will be mapped to the contents of the actual contents of the property. Replacing ^ M with an empty character will reduce the length of the property contents, hence the error.

svndumptool will change Prop-content-length and Content-length respectively.

Answer 7

I just successfully restored the svn dump file. It also had CRLF in properties, which caused an exception to import from the SVN Edge dump (they have a very poor import procedure). Then I “installed” svnserve for testing, which was much simpler than expected (instructions for Windows):

• download and install TortoiseSVN or other software that includes svn command line tools. I already installed it
• start cmd.exe , run svnserve -d . Now this cmd window is busy.
• run another cmd.exe create repo: svnadmin create d:\svn_repos\test12
• load the dump into the repo: svnadmin load d:\svn_repos\test12 < d:\temp\svn\backup_test.dump

svnserve will provide you with detailed information about what failed.

And here is what you need to repair (original on the left, repaired on the right side):