I have some filename with some Unicode character in it. All filenames on Mac OS X are UTF8 encoded. Also $LANG is set to en_US.UTF-8.

However, it seems svn has some problems with that:

az@ip212 1054 (Integration) %ls
Abbildungen                           Verbesserungsvorschläge_Applets.odt
AllgemeineAnmerkungen.rtf             Verbesserungsvorschläge_Applets.rtf
Geogebra                              Vorlagen
az@ip212 1055 (Integration) %svn ls
az@ip212 1056 (Integration) %svn del Verb*.odt
svn: Use --force to override this restriction
svn: 'Verbesserungsvorschläge_Applets.odt' is not under version control
az@ip212 1057 (Integration) %svn status
?       Verbesserungsvorschläge_Applets.odt
!       Verbesserungsvorschläge_Applets.odt
az@ip212 1058 (Integration) %

As you can see, svn del does not recognize the filename. And even svn status gets confused about it.

How can I fix this? I also tried with LC_CTYPE=$LANG LC_ALL=$LANG LC=$LANG but no change.


I got an answer from the Subversion mailinglist from B Smith-Mannschott:

This is a known issue.


One poster on the comment thread to that issue suggested as follows:

Additional comments from Julian Mehnle Thu Aug 6 07:40:30 -0700 2009:

There is a work-around: install the "unicode_path" variant of the subversion MacPorts package:

$ sudo port install subversion +unicode_path

I haven't tried this myself.

// ben

It seems to work mostly for me but I am not sure what else is broken now.

I did some investigation into the Subversion source and it seems that UTF8 filename support is broken very badly. They kind of ignore the fact that a filename can have different representations in UTF8. They handle all such different representations as different filenames. MacOSX might change the representation internally and this is what Subversion confuses a lot -- and cannot handle.

You can see in their source that their path compare function is basically just a memcpy.

I tried to fix it but I am not really sure if I did or not (and I don't want to waste much more time into it -- it seems to work now but not sure about it).

Read the upstream bug report for more details and a follow-up discussion.


As others have mentioned here and elsewhere, the root cause is as follows: For some characters, UTF-8 allows different ways to encode them (composed vs. decomposed). The file systems on macOS (HFS+ or APFS) encode filenames in the normalized decomposed form (NFD), while Subversion seems to use a different UTF-8 encoding when files are added.

So when a file named ä_¥_é_ç_Ø.txt is added from the command line:

> svn add ä_¥_é_ç_Ø.txt
A       ä_¥_é_ç_Ø.txt

Subversion stores the file name in a different encoding which leads to problems:

> svn status
?       ä_¥_é_ç_Ø.txt
!       ä_¥_é_ç_Ø.txt

The first line is about the existing file (whose name is NFD encoded). This file exists in the file system but is unknown to Subversion ("?").
The second line is about the added file (whose name is encoded differently). This file is known to Subversion but does not exist in the file system ("!")

To see the different encodings, use xxd:

> svn status | head -1 | xxd; echo; svn status | tail -1 | xxd
00000000: 3f20 2020 2020 2020 61cc 885f c2a5 5f65  ?       a.._.._e
00000010: cc81 5f63 cca7 5fc3 982e 7478 740a       .._c.._...txt.

00000000: 2120 2020 2020 2020 c3a4 5fc2 a55f c3a9  !       .._.._..
00000010: 5fc3 a75f c398 2e74 7874 0a              _.._...txt.

Here is how I deal with this to make Subversion work with UTF-8 encoded file names on macOS file systems:

When adding or removing files from Subversion, I do not type or autocomplete the file names in the Subversion command. Instead I ls the file, copy the file name, and paste it into the Subversion command, where it will show up with the encoding's actual hex codes.
Doing this causes Subversion to use the actual file name encoding instead of using a converted form.


> svn status
?       ä_¥_é_ç_Ø.txt
> ls

Copy the file name and paste it into the following command

> svn add a<0308>_¥_e<0301>_c<0327>_Ø.txt
A         ä_¥_é_ç_Ø.txt
> svn commit -m "Test"
Füge hinzu         ä_¥_é_ç_Ø.txt
Übertrage Daten .erledigt
Übertrage Transaktion...
Revision 4 übertragen.
> svn status
  • Upvote for the elaborate explanation, and while your approach might work when adding files, it doesn't help with pre-existing files. – codesniffer Mar 12 '20 at 12:48

can you export LANG=de_DE.UTF-8 ?

  • Doesn't work. And as said, I already have LANG=en_US.UTF-8 and there shouldn't really be a difference to de_DE.UTF-8 (because it is both just UTF8). – Albert Aug 28 '10 at 14:28

I got bit by this today. Server is on a Linux and two OS X clients are syncing towards it. Was trying to delete the troublesome file on the server, but even there Unicode chars are marked funnily. Maybe it's time for me to move to git?


I somehow managed to change things on the server so that the unicode double-named file issue seems to have changed into getting "Checksum mismatch while reading representation" at the end of 'svn update' or 'svn checkout'. Heh.

  • I have moved to Git 2 years ago already. And I love it! However, while the Unicode filename situation has become better, I still have such problems sometimes... – Albert Apr 14 '12 at 3:27
  • I've also used git in customer projects, and do like it. Many things s.a. renaming of a file cause way less (actually, no) problems, compared to svn. – akauppi Apr 14 '12 at 6:49
  • We have this issue only on Mac clients. Our Linux SVN server and all Linux & Windows clients work as expected. Seems to be an issue with SVN on Mac. – codesniffer Mar 12 '20 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.