> 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:brane_at_wandisco.com]
> Gesendet: Mittwoch, 17. Dezember 2014 14:05
> An: users_at_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
Received on 2014-12-17 19:28:01 CET