On Mon, Feb 29, 2016 at 07:30:14PM +0100, Vincent Lefevre wrote:
> For "svn st", I do not try to access the file. A file with an invalid
> name cannot be a versioned file anyway. So, it could also just be
> ignored, and outputting a non-fatal warning would be sufficient, IMHO.
> Note that even "svn st -q" fails!
All parts of Subversion handle paths (or any string, really) as UTF-8.
The downside is that invalid UTF-8 leads to problems like you're seeing.
The upside is that things tend to work just fine for any encoding, as long
as encodings involved are valid and configured as intended.
> Concerning svn-clean, I think that instead of failing, svn-clean
> should fallback to some alternate way. After all, a part of its code
> does not use the internal filename representation.
Fixing svn-clean to solve this problem is probably your easiest way out.
'svn cleanup --remove-unversioned' would be the built-in equivalent but
it performs a status walk internally so it won't help you :-/
svn-clean is in the contrib directory, which means it's not officially
maintained by the Subversion project itself. Please contact the author
or provide a patch.
> The problem is that it is too easy to create files with a name using
> invalid UTF-8 sequences (in my case, it seems just to be due to a bug
> in Automake or Libtool). But the user should not be required to find
> them and delete manually.
I agree this is a problem. 'svn cleanup --remove-unversioned' should
remove such files, but it won't in the current implementation.
But I doubt it's possible to solve with our current set of APIs without
breaking API guarantees Subversion provides. If you believe otherwise,
please try to write a patch to solve this and see for yourself. I imagine
that we'd quickly find ourselves hitting a barrier in form of a public API
promise that can't be broken. Perhaps we could add a special API just
for this use case, though. Would that be worth the effort?
Received on 2016-02-29 19:58:38 CET