SVN funktionierte bis vor ein paar Minuten ganz gut - ich kann immer noch mein Repository durchsuchen Ссылка , aber wenn ich es versuche Führen Sie jede Operation, einschließlich Svn up, bekomme ich:
%Vor% Und als ich svn cleanup http://svn.example.com/myrepo probiert habe, nur um zu sehen, was passieren würde, habe ich:
Nochmal: Wenn ich das in den Browser tippe, kann ich das Repository immer noch gut durchsuchen. Was ist los?
Okay, es stellt sich heraus, dass die Lösung für dieses Problem sehr einfach ist - und auch sehr kompliziert.
Die einfache Antwort:
Der Hostname svn.mywebsite.com existiert nicht (zumindest nicht so weit wie mein Entwicklungsserver).
Für jeden, der dieses Problem hat, empfehle ich dringend, das Problem von der Annahme aus zu lösen, dass Ihr Kunde den SVN-Server aus irgendeinem Grund nicht finden kann.
-
Die Komplikation:
Nun, für mich stellte sich heraus, dass es ein bisschen komplexer war, denn wie ich bereits erwähnt habe, es funktionierte - und dann hörte es auf.
Der Grund dafür, falls Sie interessiert sind, ist, dass unser SVN-Server auf einem Webserver zusammen mit unserer Hauptanwendung (in http://www.mywebsite.com ) lebt, die zufällig auf einem anderen Server gespiegelt wird und die DNS-Einträge für mywebsite.com werden auf einem AB-Muster zwischen den beiden Servern verteilt. Da der SVN-Client auf meinem Entwicklungsserver svn.mywebsite.com nicht finden konnte, suchte er einfach nach mywebsite.com . Sobald Apache mit dem Server "A" verbunden ist, auf dem die Einträge für den virtuellen Host für den SVN-Server vorhanden sind, übernahm Apache und lieferte den für svn.mywebsite.com geeigneten Inhalt.
Aber irgendwann wurde mein DNS-Cache aktualisiert, und ohne dass eine Anwendungslogik verfügbar war, um den Benutzer zurück auf den "A" -Server zu schicken, begann mein Entwicklungsserver, mywebsite.com auf den "B" -Server aufzulösen SVN wurde nicht einmal installiert.
Offensichtlich hat der SVN-Client dann angefangen zu sagen: "Oh, gee, es gibt keinen solchen Server." (Wer wusste, was OPTIONEN bla bla 200 OK bedeutet?)
Warum ich ein Idiot bin
Hier kommt der unvermeidliche ID10T Fehler ins Spiel. Der Grund, warum ich ständig zu "http://svn.mywebsite.com/myrepo" in Firefox navigieren konnte, war, weil ich manuell einen Host-Eintrag auf meinem PC erstellt hatte, der auf die IP-Adresse des "A" -Servers zeigte.
Wenn ich mich früher daran erinnert hätte, hätte ich mir viel Zeit gespart - und ein paar wertvolle Ibuprofen-Tabletten. :)
Ähnliches Problem hier mit einer anderen Ursache und Lösung.
Die einfache Antwort
Downgrade des Subversion-Clients.
Die kompliziertere Antwort
Zuvor hatte ich 1.6.11 (besonders 1.6.11-SlikSvn-tag-1.6.11@935062-X64 ) benutzt und das funktionierte gut. Auf 1.6.17 aktualisiert ( 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 ) und dann den OPTIONS of ... 200 OK Fehler erhalten. Downgrade wurde wieder behoben. All dies wurde durch die Tatsache verwirrender, dass (offensichtlich) ich das Repository in meinem Browser durchsuchen konnte, und auch in IntelliJ, das, wie ich annehme, einen eigenen SVN-Client verwendet.
Warum ich ein Idiot bin
Da ich über zwei SVN-Repositorys arbeite und das andere bei beiden Versionen des Clients funktioniert, habe ich das Problem erst einige Tage nach dem Upgrade bemerkt, so dass ich die Ursache nicht sofort herausgefunden habe. Wenn ich das früher bemerkt hätte, hätte ich mir viel Zeit gespart - obwohl ich kurz davor war, die Schmerzmittel zu schlagen!
& lt; / schamloses Plagiat von Brian Lacys Antwort & gt;
Dieser Fehler "svn: OPTIONS of" kann auch angezeigt werden, wenn Ihr Server den svn-Port verwendet, Sie aber das http-Protokoll in Ihrer URL angeben.
Das heißt, ich würde den Fehler erhalten, wenn ich es versuchte:
%Vor%Aber was hätte ich tun sollen:
%Vor%Ich habe das gleiche Problem, weil ich versucht habe, einen zweiten SVN Repo hinzuzufügen. Nachdem ich diesen Beitrag gelesen hatte, erkannte ich, dass ich einen weiteren Standort in meiner SVN Config-Datei (in meinem Fall: /etc/apache2/mods-enabled/dav_svn.conf) mit verschiedenen Pfaden hinzufügen musste . Jetzt funktioniert es nach dem Neustart von Apache.
Warum nicht noch eine Lösung für eine lächerlich mehrdeutige Fehlermeldung? In meinem Fall wurde der SVN-Repo vom Root-Benutzer erstellt, daher waren die Berechtigungen falsch.
%Vor%Und da ich SELinux betreibe, habe ich das auch gut gemacht:
%Vor%ETA:
Ein leicht zu erkennendes Symptom dieses Problems liegt in Ihren Apache-Protokollen. Beachten Sie, dass in Reaktion auf die OPTIONS-Anfrage kein Body gesendet wurde:
%Vor%Nach den Änderungen:
%Vor%Tags und Links svn