Unicode文字を含むファイル名があります。 Mac OSXのすべてのファイル名は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
でも試しましたが、変更はありません。
BSmith-MannschottのSubversionメーリングリストから回答を得ました。
これは既知の問題です。
http://Subversion.tigris.org/issues/show_bug.cgi?id=2464
その問題へのコメントスレッドの1つのポスターは、次のように提案されました。
Julian Mehnle Thu Aug 6 07:40:30 -0700 2009からの追加コメント:
そこにあります回避策:SubversionMacPortsパッケージの「unicode_path」バリアントをインストールします。
$ Sudo port install Subversion + unicode_path
私はこれを自分で試したことがありません。
//ベン
それは私にとってほとんどうまくいくようですが、他に何が壊れているのかわかりません。
Subversionソースを調査しましたが、UTF8ファイル名のサポートが非常にひどく壊れているようです。彼らは、ファイル名がUTF8で異なる表現を持つことができるという事実を無視しています。それらは、そのようなすべての異なる表現を異なるファイル名として処理します。 MacOSXは内部的に表現を変更する可能性があり、これがSubversionが多くの混乱を招き、処理できないものです。
ソースを見ると、パス比較機能は基本的に単なるmemcpyであることがわかります。
私はそれを修正しようとしましたが、私が修正したかどうかは本当にわかりません(そして私はそれにもっと多くの時間を無駄にしたくありません-それは今は動作しますが、よくわかりません)。
詳細とフォローアップディスカッションについては、アップストリームのバグレポートをお読みください。
他の人がここや他の場所で言及しているように、根本的な原因は次のとおりです。一部の文字では、UTF-8でさまざまな方法でエンコードできます(合成と分解)。 macOS(HFS +またはAPFS)のファイルシステムは、ファイル名を正規化された分解形式(NFD)でエンコードしますが、Subversionは、ファイルが追加されるときに異なるUTF-8エンコードを使用するようです。
したがって、ä_¥_é_ç_Ø.txtという名前のファイルがコマンドラインから追加された場合:
> svn add ä_¥_é_ç_Ø.txt
A ä_¥_é_ç_Ø.txt
Subversionは、ファイル名を別のエンコーディングで保存するため、問題が発生します。
> svn status
? ä_¥_é_ç_Ø.txt
! ä_¥_é_ç_Ø.txt
最初の行は、既存のファイル(名前はNFDエンコード)に関するものです。このファイルはファイルシステムに存在しますが、Subversion( "?")には認識されません。
2行目は、追加されたファイルに関するものです(名前のエンコードが異なります)。このファイルはSubversionに認識されていますが、ファイルシステムに存在しません( "!")
さまざまなエンコーディングを表示するには、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.
これに対処して、MacOSファイルシステムでSubversionをUTF-8でエンコードされたファイル名で機能させる方法を次に示します。
Subversionからファイルを追加または削除するとき、Subversionコマンドでファイル名を入力またはオートコンプリートしません。代わりに、ファイルをls
し、ファイル名をコピーして、Subversionコマンドに貼り付けます。ここで、エンコードの実際の16進コードが表示されます。
これを行うと、Subversionは変換されたフォームを使用する代わりに実際のファイル名エンコーディングを使用します。
例:
> svn status
? ä_¥_é_ç_Ø.txt
> ls
ä_¥_é_ç_Ø.txt
ファイル名をコピーして、次のコマンドに貼り付けます
> 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
>
今日はこれに噛まれました。サーバーはLinux上にあり、2つのOSXクライアントがそれに向かって同期しています。サーバー上の厄介なファイルを削除しようとしましたが、Unicode文字がおかしなことにマークされています。多分それは私がgitに移動する時間ですか?
補遺:
私はどういうわけかサーバー上のものを変更して、Unicodeのダブルネームファイルの問題が「svnupdate」または「svncheckout」の最後に「 表現の読み取り中にチェックサムの不一致 」を取得するように変更されたように見えるようにしました'。ふふ。
あなたはできる export LANG=de_DE.UTF-8
?