[Tollef Fog Heen] > I just stumbled across one issue: it doesn't handle the case where > you change your encoding without checking out the repository again: > > : [EMAIL PROTECTED] ~/svn/trunk > LANG=en_US.UTF-8 svn st > svn: Valid UTF-8 data > (hex: 46) > followed by invalid UTF-8 sequence > (hex: f8 72 73 74)
That's a design decision - to recode filenames to a user's locale. This enables users with different locales to all see the same filenames in their local checkouts. You can argue that it's good or bad, but the alternative is *not* to recode them, and that causes exactly the same problem, when users of the same repository use different locales. So when local filenames are in the "wrong" locale (for whatever reason), what *should* the software do? Or, another point: most software does not keep an internal database of the encoding used for its data filenames. Do you think subversion should? > Yeah, and there's another error if you use LANG=C: > : [EMAIL PROTECTED] ~/svn/trunk > LANG=C svn st > svn: Can't convert string from native encoding to 'UTF-8': > svn: F?\248rste informasjonsskriv.doc Given the decision to store filenames in UTF-8 in the repository, I don't know what else svn could possibly do here. The filename in question is, after all, invalid in the C locale. Peter
signature.asc
Description: Digital signature
