Problem mit der SVN-Dateinamencodierung unter Mac OS X.

Ich habe einen Dateinamen mit einem Unicode-Zeichen. Alle Dateinamen unter Mac OS X sind UTF8-codiert. Auch $LANGist eingestellt auf en_US.UTF-8.

Es scheint svnjedoch einige Probleme damit zu haben:

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) %

Wie Sie sehen können, svn delerkennt der Dateiname nicht. Und wird sogar svn statusverwirrt.

Wie kann ich das beheben? Ich habe es auch mit LC_CTYPE=$LANG LC_ALL=$LANG LC=$LANGaber ohne Veränderung versucht .

Ich habe eine Antwort von der Subversion-Mailingliste von B Smith-Mannschott erhalten:

Dies ist ein bekanntes Problem.

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

Ein Poster im Kommentarthread zu diesem Thema schlug Folgendes vor:

Zusätzliche Kommentare von Julian Mehnle Do 6. August 07:40:30 -0700 2009:

Es gibt eine Problemumgehung: Installieren Sie die Variante "unicode_path" des Subversion-MacPorts-Pakets:

$ sudo port install subversion + unicode_path

Ich habe das selbst nicht versucht.

// ben

Es scheint hauptsächlich für mich zu funktionieren, aber ich bin mir nicht sicher, was jetzt noch kaputt ist.

Ich habe einige Nachforschungen über die Subversion-Quelle angestellt und es scheint, dass die Unterstützung für UTF8-Dateinamen sehr schlecht ist. Sie ignorieren die Tatsache, dass ein Dateiname in UTF8 unterschiedliche Darstellungen haben kann. Sie behandeln alle so unterschiedlichen Darstellungen als unterschiedliche Dateinamen. MacOSX kann die Darstellung intern ändern, und dies ist es, was Subversion sehr verwirrt - und nicht verarbeiten kann.

Sie können in ihrer Quelle sehen, dass ihre Pfadvergleichsfunktion im Grunde nur ein Memcpy ist.

Ich habe versucht, das Problem zu beheben, bin mir aber nicht sicher, ob ich es getan habe oder nicht (und ich möchte nicht viel mehr Zeit damit verschwenden - es scheint jetzt zu funktionieren, ist mir aber nicht sicher).

Lesen Sie den Upstream-Fehlerbericht für weitere Details und eine anschließende Diskussion.

Wie andere hier und anderswo erwähnt haben, ist die Hauptursache folgende: Für einige Zeichen erlaubt UTF-8 verschiedene Arten, sie zu codieren (zusammengesetzt oder zerlegt). Die Dateisysteme unter macOS (HFS + oder APFS) codieren Dateinamen in der normalisierten zerlegten Form (NFD), während Subversion beim Hinzufügen von Dateien eine andere UTF-8-Codierung zu verwenden scheint.

Wenn also eine Datei mit dem Namen ä_ ¥ _é_ç_Ø.txt über die Befehlszeile hinzugefügt wird:

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

Subversion speichert den Dateinamen in einer anderen Codierung, was zu Problemen führt:

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

In der ersten Zeile geht es um die vorhandene Datei (deren Name NFD-codiert ist). Diese Datei existiert im Dateisystem, ist Subversion jedoch nicht bekannt ("?").
In der zweiten Zeile geht es um die hinzugefügte Datei (deren Name unterschiedlich codiert ist). Diese Datei ist Subversion bekannt, existiert jedoch nicht im Dateisystem ("!")

Verwenden Sie xxd, um die verschiedenen Codierungen anzuzeigen:

> 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.

So gehe ich damit um, damit Subversion mit UTF-8-codierten Dateinamen auf macOS-Dateisystemen funktioniert:

Beim Hinzufügen oder Entfernen von Dateien zu Subversion werden die Dateinamen im Befehl Subversion nicht eingegeben oder automatisch vervollständigt. Stattdessen lskopiere ich die Datei, kopiere den Dateinamen und füge ihn in den Subversion-Befehl ein, wo er mit den tatsächlichen Hex-Codes der Codierung angezeigt wird.
Dadurch verwendet Subversion die tatsächliche Dateinamencodierung anstelle eines konvertierten Formulars.

Beispiel:

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

Kopieren Sie den Dateinamen und fügen Sie ihn in den folgenden Befehl ein

> 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
> 

können Sie export LANG=de_DE.UTF-8?

Ich habe heute etwas davon mitbekommen. Der Server befindet sich unter Linux und zwei OS X-Clients synchronisieren sich darauf. Ich habe versucht, die problematische Datei auf dem Server zu löschen, aber selbst dort sind Unicode-Zeichen lustig markiert. Vielleicht ist es Zeit für mich, zu Git zu wechseln?

Nachtrag:

Ich habe es irgendwie geschafft, die Dinge auf dem Server so zu ändern, dass sich das Problem mit der doppelt benannten Unicode-Datei anscheinend dahingehend geändert hat, dass am Ende von 'svn update' oder 'svn checkout' " Checksum Mismatch beim Lesen der Darstellung " angezeigt wird. Heh.