On Mon, May 30, 2011 at 11:47:30PM +0200, Torsten Krah wrote:
> If <1.6 did not enforce this and 1.6 does - why does 1.6 not recode it
> at the time it does encounter such "things" - at least via some optional
> command line option?
I think that is something we should add, yes.
We should also make svnadmin verify complain if paths are not in UTF-8.
That is two issues to file into our tracker right there.
Note that svnsync already has this kind of feature to handle badly
encoded revision properties.
> Do you really want to tell me that subversion (the "tool" used to manage
> my code) is not able to load its own "dump", at least by providing some
> "fix" tool by itself if it did things not "right" before - why should i
> need or bother with "third-party" tools here - this should be done by
> svn, shouldn't it?
Note that the API documentation for Subversion has always been saying
that paths are expected to be in UTF-8. It's just that the code didn't
enforce it. What probably happened here is that some third-party client
was used to add this file originally, and this third party client did
not convert the pathname to UTF-8 before sending it to the repository.
The standard svn client has been converting paths to UTF-8 since before 1.0.
Of course, that does not excuse the Subversion server's behaviour.
It should have verified the input and rejected the commit as invalid.
Alas, this verification step was only added in 1.6.
> > If none of the third-party dump manipulation tools can do
> > that,
>
> Which "third-party" tools you have in mind are able to do that for me?
A nice one is svndumptool: http://svn.borg.ch/svndumptool/
But it doesn't look like it has the feature you need.
I suppose the kind of corruption problem you are having is very rare.
If this was a common problem there would already be tool support for fixing it.
Received on 2011-05-31 00:09:22 CEST