Hallo,
ich hoffe jemand hat eine Lösung für mein Problem, den Google hat mich
hier nicht weiter gebracht.
Ich möchte unter Suse 9.2 auf mein Subversion Repository, daß auf einem
Suse 9.1 Server eingerichtet ist, zugreifen.
"rpm -q -v subversion" auf dem server (Suse 9.1) ergibt:
subversion-1.1.3-7.1
"rpm -q -v subversion" auf dem Arbeitsrechner (Suse 9.2) ergibt:
subversion-1.1.3-7.1
Versuche ich nun ein
svn import <verzeichnis> svn://<servername>/<verzeichnis>
bekomme ich nach kurzer Zeit folgende Fehlermeldung:
----------
svn: Valid UTF-8 data
(hex:)
followed by invalid UTF-8 sequence
(hex: b0 33 06 08)
svn: Ihre Log-Meldung wurde in einer Temporärdatei abgelegt:
svn: 'svn-commit.4.tmp'
----------
Hierzu gibt Google zwar ein paar treffer aus, aber nichts was mich
weiter bringt.
Ich habe bereits mehrere Verzeichnisse, auch schon einfache Textdateien
probiert, immer mit der obigen Fehlermeldung (Hex code können abweichen)
Versuche ich das ganze unter Windows mit TortoiseSVN klappt alles
wunderbar. (Gibt es sowas nicht auch für den Konqueror ?)
Ich bin mit meinem Latein am Ende.
Ich hoffe jemand hat mir einen guten Ratschlag, wie ich das ganze ans
laufen bringen kann.
Danach muß das ganze nur noch in KDevelop integriert werden, aber das
ist ein anderes Problem.
Danke für Eure Hilfe
Juergen
--
Juergen Sachs
Hi Jürgen! Juergen Sachs schrieb am 27.03.2005 19:28 :
svn: Valid UTF-8 data (hex:) followed by invalid UTF-8 sequence (hex: b0 33 06 08)
Anscheinend müssen für UTF besondere Vorbereitungen getroffen werden. Ich vermute, dies, da dies bei den Versionshinweisen zu RapidSVN 0.8 steht: http://rapidsvn.tigris.org/ | Emphasis on... | complete utf8 support (so french accents and german umlauts work!) Weitere Clients findest du hier (vielleicht hat ja ein Linux-Client schon kompletten UTF-Support?): http://subversion.tigris.org/project_links.html Interessant könnte für dich zudem die Lektüre dieses Buchs sein: http://svnbook.red-bean.com/en/1.1/svn-book.html Dort findest du u.a. diese Optionen: | log-encoding | | This variable sets the default character set encoding for commit log | messages. It's a permanent form of the --encoding option (see the | section called “svn Switches”.) The Subversion repository stores log | messages in UTF8, and assumes that your log message is written using | your operating system's native locale. You should specify a different | encoding if your commit messages are written in any other encoding. | --encoding ENC | | Tells Subversion that your commit message is encoded in the charset | provided. The default is your operating system's native locale, and | you should specify the encoding if your commit message is in any other | encoding. Kann es sein, dass die Log-Message bei dir in UTF-16 verfasst wurde und Subversion fälschlicherweise annimmt, dass es sich um UTF-8 handelt? Dann solltest du wohl mit diesen Switches dein Glück finden. Gruß, Michael
Am Sonntag, den 27.03.2005, 20:36 +0200 schrieb Michael Wenger: Hi Michael, Durch die Clients bin ich schon durch, ich habe gehoft es gibt noch ne gute Seite, aber das ist jetzt nicht das wichtigste :-) Durch das Buch bin ich glaub schon durch, die Option hat leider nicht geholfen. Ich habe auch nochmal einen checkout versucht. Mit dem Kommandozeilen "svn" und "esvn". Das Ergebnis ist leider das gleiche. Es scheint also nicht am Format des "commit-log" zu liegen (außer ich hab da was noch nicht verstanden?!) Auch habe ich einen Checkout direkt auf dem Server versucht. Das gleiche Ergebnis. Ich bin noch am Überlegen ob ich einen Versuch mit der mitgelieferten Suberversion Version von Suse 9.2 versuchen soll. Die ist allerdings schon recht alt (1.0.8). Soweit ich weis, ist Suse ab Version 9.1 per default auf UTF8 eingestellt. Das Format SOLLTE also passen. allerdings weis ich nicht wie ich das prüfen sollte...
Juergen Sachs schrieb am 27.03.2005 19:28 :
svn: Valid UTF-8 data (hex:) followed by invalid UTF-8 sequence (hex: b0 33 06 08)
Anscheinend müssen für UTF besondere Vorbereitungen getroffen werden. Ich vermute, dies, da dies bei den Versionshinweisen zu RapidSVN 0.8 steht: http://rapidsvn.tigris.org/ | Emphasis on... | complete utf8 support (so french accents and german umlauts work!)
Weitere Clients findest du hier (vielleicht hat ja ein Linux-Client schon kompletten UTF-Support?): http://subversion.tigris.org/project_links.html
Interessant könnte für dich zudem die Lektüre dieses Buchs sein: http://svnbook.red-bean.com/en/1.1/svn-book.html Dort findest du u.a. diese Optionen: | log-encoding | | This variable sets the default character set encoding for commit log | messages. It's a permanent form of the --encoding option (see the | section called “svn Switches”.) The Subversion repository stores log | messages in UTF8, and assumes that your log message is written using | your operating system's native locale. You should specify a different | encoding if your commit messages are written in any other encoding.
| --encoding ENC | | Tells Subversion that your commit message is encoded in the charset | provided. The default is your operating system's native locale, and | you should specify the encoding if your commit message is in any other | encoding.
Kann es sein, dass die Log-Message bei dir in UTF-16 verfasst wurde und Subversion fälschlicherweise annimmt, dass es sich um UTF-8 handelt? Dann solltest du wohl mit diesen Switches dein Glück finden.
Gruß, Michael
--
Juergen Sachs
Hi Jürgen! Juergen Sachs schrieb am 27.03.2005 23:17 :
Ich bin noch am Überlegen ob ich einen Versuch mit der mitgelieferten Suberversion Version von Suse 9.2 versuchen soll. Die ist allerdings schon recht alt (1.0.8).
Soweit ich weis, ist Suse ab Version 9.1 per default auf UTF8 eingestellt. Das Format SOLLTE also passen. allerdings weis ich nicht wie ich das prüfen sollte...
Ich muss gestehen, dass mein Subversion-Server auf Debian läuft und mein Client auf Windows (TortoiseSVN), daher kann ich dir nicht wirklich helfen. Allerdings habe ich in den Google-Untiefen dieses Posting ausgemacht: http://svn.haxx.se/users/archive-2004-06/0907.shtml Wenn du WebDAV benutzt, könnte das vielleicht die Ursache sein. Um herauszufinden, ob du wirklich in UTF8 arbeitest, würde ich einfach diese Zeile absetzen und danach die Größe der Datei ansehen: echo -en ö > /tmp/utftest Wenn sie genau 2 Bytes groß ist, ist die Wahrscheinlichkeit sehr hoch, dass du mit UTF-8 arbeitest. Gruß, Michael
Am Sonntag, den 27.03.2005, 23:42 +0200 schrieb Alexander Veit:
> Laufen alle beteiligten Prozesse (Client und Server) mit denselben LC_CTYPE?
Das ist eine gute Frage....
Ich habe das Paket von
"ftp://ftp.suse.com/pub/people/poeml/subversion/9.1-i386/subversion-1.1.3-7.1.i586.rpm" auf meinem Server Installiert und das Repository nach dem "Subversion Book" eingerichtet. Auf meinem Arbeitsrechner das gleiche Packet nur für Suse 9.2.
Ich habe gerade folgenden Test auf dem Server gemacht:
- eine Textdatei Neu erstellt.
- Diese mit "svn import test svn://linuxserver/test" importiert, was
Problemlos funktioniert hat ("Test" ist eine mit "vi" erstellte Text
Datei).
- Das gleiche hab ich auch nochmal von meinem Arbeitsrechner aus
versucht. Funktionierte ebenfalls problemlos.
Da bleibt mir nur eine Vermutung. Da meine Projekte, die ich nun in
Subversion aufnehmen möchte, schon sehr lange existieren, sind dies noch
nicht per UTF8 kodiert :-(
Ich werde mich hier wohl nochmals mit der UTF8 Konvertierung meiner
ganzen Projekte auseinander setzen müssen :-( (HTML und C++ Projekte)
Jemand eine guten Tip wie das einfach geht ?
Ich werde nun mal Googeln gehn zu der Problematik.
Danke für die Tips.
Juergen
> Juergen Sachs schrieb:
> > [...]
> > svn: Valid UTF-8 data
> > (hex:)
> > followed by invalid UTF-8 sequence
> > (hex: b0 33 06 08)
> Gruß,
> Alex
>
>
--
Juergen Sachs
--
Juergen Sachs
Juergen Sachs schrieb:
[...] Da bleibt mir nur eine Vermutung. Da meine Projekte, die ich nun in Subversion aufnehmen möchte, schon sehr lange existieren, sind dies noch nicht per UTF8 kodiert :-(
Das wäre sehr eigenwillig. Ein Versionsverwaltungssystem sollte nicht nur dann funktionieren, wenn die Quelltexte ein bestimmtes Encoding haben. Gibt es beim Subversion-Client keine Möglichkeit, das Encoding der Dateien zu spezifizieren? Alex
Am Montag, den 28.03.2005, 14:22 +0200 schrieb Alexander Veit:
Juergen Sachs schrieb:
[...] Da bleibt mir nur eine Vermutung. Da meine Projekte, die ich nun in Subversion aufnehmen möchte, schon sehr lange existieren, sind dies noch nicht per UTF8 kodiert :-(
Das wäre sehr eigenwillig. Ein Versionsverwaltungssystem sollte nicht nur dann funktionieren, wenn die Quelltexte ein bestimmtes Encoding haben. Gibt es beim Subversion-Client keine Möglichkeit, das Encoding der Dateien zu spezifizieren? Es gibt den Parameter "--encoding ENC" führte aber auch zu keinem Erfolg :-( Allerdings muste ich auch feststellen, das eine fehlerhafte Angabe für "ENC" keine Fehlermeldung abgibt. Eventuell habe ich also auch eine ungültige Eingabe für "--encoding" gemacht. Allerdings habe ich auch keine Liste für die gültigen Angaben gefunden. Versucht habe ich "UTF8" und "latin1". In welchem Format meine Texte kodiert sind weis ich allerdings nicht. Der direkte Import nur 1 einzelnen Datei des Projektes hat Problemlos funktioniert. Irgendwie dreh ich mich im Kreis.
Schon frustrierend, wenn man sieht wie einfach es unter Windows geht :-(
Aber ich gebe nicht auf.
Juergen
--
Juergen Sachs
Juergen Sachs schrieb:
[...] Es gibt den Parameter "--encoding ENC" führte aber auch zu keinem Erfolg :-( Allerdings muste ich auch feststellen, das eine fehlerhafte Angabe für "ENC" keine Fehlermeldung abgibt. Eventuell habe ich also auch eine ungültige Eingabe für "--encoding" gemacht. Allerdings habe ich auch keine Liste für die gültigen Angaben gefunden. Versucht habe ich "UTF8" und "latin1". In welchem Format meine Texte
Häufigere und wahrscheinlich korrektere Bezeichnungen dafür sind UTF-8 und ISO-8859-1. Wenn ich das svn-Book richtig interpretiere, sollte sich der Parameter aber nur auf Commit-Logmessages auswirken.
kodiert sind weis ich allerdings nicht. Der direkte Import nur 1 einzelnen Datei des Projektes hat Problemlos funktioniert. Irgendwie dreh ich mich im Kreis.
Kannst Du eine einzelne Datei isolieren, mit der es nicht geht? Evtl. hängt es am Dateinamen oder -pfad und nicht am Dateiinhalt. Sagen die Serverlogs etwas zu dem Fehler? Alex
Am Montag, den 28.03.2005, 15:33 +0200 schrieb Alexander Veit:
Häufigere und wahrscheinlich korrektere Bezeichnungen dafür sind UTF-8 und ISO-8859-1. Wenn ich das svn-Book richtig interpretiere, sollte sich der Parameter aber nur auf Commit-Logmessages auswirken. Hat leider auch keine Änderung gebracht.
kodiert sind weis ich allerdings nicht. Der direkte Import nur 1 einzelnen Datei des Projektes hat Problemlos funktioniert. Irgendwie dreh ich mich im Kreis.
Kannst Du eine einzelne Datei isolieren, mit der es nicht geht? Evtl. hängt es am Dateinamen oder -pfad und nicht am Dateiinhalt. Sagen die Serverlogs etwas zu dem Fehler? Ich hab eines Projekte in ein neu angelegtes Verzeichnis kopiert und abgespeckt. Jedes File einzeln mit svn import <Dateiname> svn://<servername>/test1/<Dateiname> -m "test" importiert. Ohne Probleme. Danach habe ich versucht das ganze Verzeichnis mit svn import svntest svn://<servername>/test2/ -m "test" zu importieren. Was immer wie folgt fehlschlägt:
svn: Valid UTF-8 data
(hex:)
followed by invalid UTF-8 sequence
(hex: b0 33 06 08)
----
Die Hex-Sequenz ist wohl immer die gleiche.
Was ich noch vergessen habe, ich nutze nicht Apache als Server, sondern
den "svnserv -d" als Server dienst. Ich habe hier keine Logdateien
gefunden auch nicht in den Systemlogs.... Aber vielleicht suche ich ja
an der falschen Stelle.
Ich werde das Gefühl nicht los, das die Suse RPMs einen Bug haben. Auf
der Subversion user list habe ich im Archiv jemanden gefunden der das
gleiche Problem hat. Bisher keine Antwort leider.
Ich werde wohl dort auch mal eine Anfrage starten....
Danke für die Tips.
Juergen
--
Juergen Sachs
Hi Jürgen! Vielleicht liegts ja auch an der verwendeten Version der libdb? AFAIK ist derzeit die libdb4.2 für svnserve empfohlen. Gruß, Michael
Hi Jürgen! Juergen Sachs schrieb am 28.03.2005 15:01 :
Allerdings habe ich auch keine Liste für die gültigen Angaben gefunden. Versucht habe ich "UTF8" und "latin1". In welchem Format meine Texte kodiert sind weis ich allerdings nicht.
Hier gibt es eine Liste aller gebräuchlichen encodings: http://www.iana.org/assignments/character-sets Ich würde diese hier durchprobieren: US-ASCII ISO-8859-1 ISO-8859-15 UTF-16 Gruß, Michael
participants (3)
-
Alexander Veit -
Juergen Sachs -
Michael Wenger