On Mar 21, 2008, at 12:27, Samuel Langlois wrote:
> Because of a hardware failure, we had to restore our nightly
> subversion dump.
> We are using 1.3.2 on Linux with fsfs (Apache/2.2.2 (Unix) mod_ssl/
> 2.2.2 OpenSSL/0.9.7a DAV/2 SVN/1.3.2)
>
> After 2 hours of feverish restore, the "svnadmin load" failed with
> the message:
> File not found: transaction '84072-1', path 'JRules/branches/
> v65updates/localization/ja/tutorials/shared-jp/ã ã¼ã³æ
> ¤è¨¼ã«ã¼ã«/ã¯ã¨ãªã¼'
> The strange characters at the end are supposed to be Japanese chars
> that the term cannot display.
>
> We finally managed to restore the dump by using svndumpfilter to
> exclude this path and several others. All of the paths which were
> causing problems had Chinese or Japanese characters.
> But most paths with such characters worked correctly: only a few
> were crashing the restore.
>
> I was able to extract one part of the dump to reproduce the problem:
> ftp://ftp.ilog.fr/private/JRules/chinese.svndump.gz
> To reproduce, do the following:
> svnadmin create chineserep
> svn mkdir file://`pwd`/chineserep/trunk
> svnadmin load chineserep < chinese.svndump
>
> I tried re-importing it with subversion 1.4.6, but I had the same
> error.
> I suppose the problem happens during the dump, not the restore.
>
> Is this a known problem with multibyte encodings?
> Would it be corrected in a newer version, or do you want me to
> register an issue?
For one thing, is your LANG environment variable set correctly? When
I set it to a correct value on my system, the error message instead
says:
svnadmin: File not found: transaction '1-1', path 'trunk/shared-zh/
squery-贷款审批-规则/规则/验证/贷款/检查总额.brl'
Now my question to you is whether that file exists in the dump or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-21 19:32:24 CET