> The most common way for decomposed characters to find their way into the > repository is by using an OSX-based Subversion client to create the paths.
You've right. What probably happened is that a person with an iMac created the document wich was checked in by an non OSX user. Maybe we just have to pay attention with OSX-Files. > -----Ursprüngliche Nachricht----- > Von: Branko Čibej [mailto:br...@wandisco.com] > Gesendet: Mittwoch, 17. Dezember 2014 14:05 > An: users@subversion.apache.org > Betreff: Re: AW: svnlook proplist & unicode characters > > On 17.12.2014 11:27, Philip Martin wrote: > > Your mail included svnlook: E160013: Pfad »/a/o¨« existiert nicht and > > what I see is 'o' '0xC2' '0xA8' so the decomposed character U+0308 has > > been converted to U+00A8. > > U+0308 is not a decomposed character; it is the combining diaeresis > mark. U+00A8 is the non-combining diaeresis (from the Latin 1 subset), > so something along the line must have performed an incorrect conversion > from the combining to the non-combining character. > > The correct decomposed representation of ö is U+006F U+0308, but the > output of svnlook has U+006F U+00A8 ... which means that some process > converted the Unicode string without any awareness of combining > characters. > > I couldn't guess which process that would be, but on Windows, Subversion > uses the Windows API for character set conversion. On Windows, > characters entered by any standard input method are precomposed. The > most common way for decomposed characters to find their way into the > repository is by using an OSX-based Subversion client to create the paths. > > -- Brane > > -- Brane
