2

I'm syncing a bunch of repositories from one machine to another; one repository fails with this error:

svnsync: Cannot accept 'svn:log' property because it is not encoded in UTF-8

This seems to be a frequently asked question, but I'm struggling with these answers:

It seems like svnsync should tell me which revision it's unable to import, but it gives no such clue. Assuming it was struggling with rev 1, I did this:

$ svn propget --revprop -r1 --strict svn:log | hexdump -C
00000000  69 6e 69 74 69 61 6c 20  63 68 65 63 6b 69 6e 0d  |initial checkin.|
00000010  0a 0d 0a 5b 69 6d 70 6f  72 74 65 64 20 66 72 6f  |...[imported fro|
00000020  6d 20 43 56 53 20 62 79  20 63 76 73 32 70 34 20  |m CVS by cvs2p4 |
00000030  61 74 20 32 30 30 35 2f  30 37 2f 30 35 20 31 35  |at 2005/07/05 15|
00000040  3a 34 30 3a 32 36 5d 0d  0a                       |:40:26]..|
00000049

But that all looks like reasonable 7-bit ASCII, so UTF-8 should accept it.

I think all I need to know is which revision has the bad svn:log property; then I can fix it using svn propedit. So how do I find the bad revision(s)?

Community
  • 1
  • 1
Chris Jones
  • 4,815
  • 6
  • 34
  • 28

1 Answers1

2

It will be the next revision after the one you've seen the Committed message for. For example I took and manually edited a repository to have invalid data in svn:log for revision 3. Then I did a sync to another repo and got this output:

$ svnsync sync file://`pwd`/dest
Transmitting file data .
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .
Committed revision 2.
Copied properties for revision 2.
svnsync: Cannot accept 'svn:log' property because it is not encoded in UTF-8

The patch you referenced had the option renamed to --source-prop-encoding and was added with 1.7.0. If you expect your svn:log properties to be UTF-8 then you probably just want to keep fixing them as you dump though I'd guess that this may be a sign that something is corrupted in the source repository.

If you know that your svn:log properties are not in UTF-8 then I'd suggest that you use a newer version of Subversion with the --source-prop-encoding option.

You can use Subversion 1.7.x binaries to do the sync even if you want to maintain compatibility with a 1.6.x server/client. For one thing old format repositories can always be read/written by newer versions. But also the format for the repository didn't change between 1.6.x and 1.7.x.

You can of course build your own copy of 1.7.x and then run the svnsync out of the build tree $BUILDDIR/subversion/svnsync/svnsync or you can download and use a pre-built binary.

My suggestion would be just to go to 1.8.x, 1.6.x is no longer supported by the Apache Subversion project. Like I mentioned above you can maintain compatibility with a 1.6.x server, in fact you can even create a 1.6.x repository with a 1.8.x svnadmin command by doing svnadmin create --compatible-version=1.6.

One last thought. Are you sure you have Subversion 1.6.17? The svn:log you reference has CRLF line endings which isn't considered to be valid for svn:* properties. Starting with Subversion 1.6.3 we started normalizing line endings to LF in svn:* properties. Using 1.6.24 that log message transfers though I get a note that it normalized properties to LF line endings.

Ben Reser
  • 5,695
  • 1
  • 21
  • 29
  • Great answer; thanks. The server is using 1.6, but the repo itself is pretty old, back from probably 1.4 or earlier. My conversion job errored out the first time, and I restarted it after losing the original output. So I couldn't tell what revision was actually giving the errors. In the end, I compiled 1.7 and used the latin-1 encoding. – Chris Jones Nov 25 '13 at 04:31