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

Re: Unversioned files with invalid UTF-8 sequence in name confuse svn

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 29 Feb 2016 19:58:26 +0100

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

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