On 2016-02-29 17:00:01 +0100, Bert Huijben wrote:
> The problem is most likely not that they have an invalid utf-8 sequence in
> their name, but that your settings report that filenames are encoded in one
> way, while there is a file which name can't be expressed by that format.
>
> You get this error when Subversion isn't able to convert the filename to its
> internal utf-8 format, which should be capable to express any valid
> filename. (If you declare that all filenames are utf-8, there wouldn't be a
> conversion, so in most cases not an error)
>
> To just handle it as unversioned as you suggest we need to at least be able
> to express its name.
There are two ways to express a filename:
1. The only from the OS (e.g., in POSIX, this is just a sequence
of bytes).
2. The one used by Subversion internally.
(2) is necessary for versioned files, but for unversioned files,
you do not need to do the (1) -> (2) conversion.
> As you found out cleanup is not going to help here... we just can't access
> this file (or directory, or symlink), so we can't delete it or anything to
> help you.
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!
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.
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.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
