[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin: Path '....' is not in UTF-8 - svnadmin load fails

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 30 May 2011 23:54:17 +0200

On Tue, May 31, 2011 at 12:30:54AM +0300, Daniel Shahaf wrote:
> 1.6 checks that paths are in UTF-8 at the time they enter the
> repository. This was always required but not always enforced.
>
> Solution is to recode the pathnames (those that are neither in ASCII nor
> in UTF-8).

Yes, that's what needs to be done. Pathnames must be encoded UTF-8.
Unfortunately it seems that this invalid pathname somehow entered the
repository when a server version was used that didn't enforce UTF-8
encoding.

I would try to edit the dump file with a hexeditor and replace the
offending two bytes with two spaces (or the proper UTF-8 character
if you know what should be there and the UTF-8 sequence has the same
number of bytes). I hope the number of paths affected by this problem
is small enough to keep this solution practical.

> If none of the third-party dump manipulation tools can do that,

... then we should provide our users with a way of fixing it,
as we did for e.g. badly encoded revision properties.

> then you could patch svnsync or one of those tools to do the
> recoding. (just inject a filename-recoding editor at the right place)

Daniel, please keep in mind that this is the *users* list.
Maybe Torsten would like to try this, but I doubt that modifying
Subversion's code is the kind of advice he was looking for.
And I really don't think that this suggestion is something that people
who are not familiar with Subversion's code base should attempt to do.
If people modify the code without understand it well the chances of
unintentionally breaking things are way too high.

It's bad enough that Torsten has to edit the dump file to fix this.
Received on 2011-05-30 23:54:58 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.