Проблема с кодировкой имени файла SVN в Mac OS X

Question

У меня есть имя файла с символом Unicode. Все имена файлов в Mac OS X имеют кодировку UTF8. Также для $LANG установлено значение en_US.UTF-8 .

Однако, похоже, у svn есть некоторые проблемы с этим:

az@ip212 1054 (Integration) %ls
Abbildungen                           Verbesserungsvorschläge_Applets.odt
AllgemeineAnmerkungen.rtf             Verbesserungsvorschläge_Applets.rtf
Geogebra                              Vorlagen
Texte
az@ip212 1055 (Integration) %svn ls
Abbildungen/
AllgemeineAnmerkungen.rtf
Geogebra/
Texte/
Verbesserungsvorschläge_Applets.rtf
Verbesserungsvorschläge_Applets.odt
Vorlagen/
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) %

Как видите, svn del не распознает имя файла. И даже svn status запутывается по этому поводу.

Как я могу это исправить? Я также пытался с LC_CTYPE=$LANG LC_ALL=$LANG LC=$LANG но без изменений.

Answer 1

Я получил ответ из списка рассылки Subversion от B Smith-Mannschott:

Это известная проблема.

http://subversion.tigris.org/issues/show_bug.cgi?id=2464

Один постер в ветке комментариев к этому вопросу предложил следующее:

Дополнительные комментарии от Julian Mehnle Thu 6 августа 07:40:30 -0700 2009:

Существует обходным: установить "unicode_path" вариант MacPorts пакета диверсии:

$ sudo port install subversion +unicode_path

Я не пробовал это сам.

// бен

Кажется, это работает в основном для меня, но я не уверен, что еще сломано сейчас.

Я провел некоторое исследование источника Subversion, и кажется, что поддержка имени файла UTF8 сломана очень плохо. Они как бы игнорируют тот факт, что имя файла может иметь разные представления в UTF8. Они обрабатывают все такие разные представления как разные имена файлов. MacOSX может изменить представление внутри, и это то, что Subversion сильно смущает - и не может справиться.

Вы можете видеть в их источнике, что их функция сравнения пути в основном просто memcpy.

Я пытался это исправить, но я не совсем уверен, сделал я это или нет (и я не хочу тратить на это гораздо больше времени - похоже, это работает сейчас, но не уверен в этом).

Прочитайте отчет об ошибках в вышестоящей версии для более подробной информации и последующего обсуждения.

Answer 2

Я получил немного сегодня. Сервер установлен на Linux, и два клиента OS X синхронизируются с ним. Пытался удалить проблемный файл на сервере, но даже там символы Unicode отмечены как ни странно. Может быть, пришло время для меня, чтобы перейти к мерзавцу?

Приложение:

Мне каким-то образом удалось что-то изменить на сервере, чтобы проблема с двойным именем файла в Юникоде, похоже, перешла в « несоответствие контрольной суммы при чтении представления » в конце «svn update» или «svn checkout». Хех.

Answer 3

Вы можете export LANG=de_DE.UTF-8 ?