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?
