SVN działa poprawnie, a następnie "svn: OPCJE 200 OK" błąd i "nie istnieje"

Question

SVN działał dobrze, aż kilka minut temu - nadal mogę przeglądać moje repozytorium pod http://svn.example.com/myrepo, ale kiedy próbuję wykonać dowolną operację , w tym svn up, otrzymuję:

svn: OPTIONS of 'http://svn.example.com/myrepo': 200 OK (http://svn.example.com) 

A kiedy próbowałem svn cleanup http://svn.example.com/myrepo po prostu zobaczyć, co by się stało, mam:

svn: 'http://svn.example.com/myrepo' does not exist 

Again - wpisując, że w przeglądarce, nadal mogę przeglądać repozytorium jest w porządku. Co się dzieje??

Answer 1

Okay, więc okazuje się, że rozwiązanie tego problemu było bardzo proste: – , a także bardzo skomplikowane.

Prosta odpowiedź:

Nazwa hosta svn.mywebsite.com nie istnieje (a przynajmniej nie tak daleko, jak mój serwer rozwoju jest zaniepokojony).

Dla każdego, kto ma ten problem, zdecydowanie radzę podejść do problemu z założenia, że ​​z jakiegokolwiek powodu, twój klient po prostu nie może zlokalizować serwera SVN.

-

Powikłanie:

Teraz dla mnie, okazało się, że to trochę bardziej skomplikowane, bo jak już wspomniałem wcześniej, to działa - a potem zatrzymał się.

Powodem tego, w przypadku zainteresowania, jest to, że nasz serwer SVN mieszka na serwerze WWW wraz z naszym głównym aplikacji (znajdującej się http://www.mywebsite.com), co zdarza się lustrzanego na innym serwerze, i DNS rekordy dla mywebsite.com są dystrybuowane na wzorzec AB między dwoma serwerami. Ponieważ klient SVN na moim serwerze programistycznym nie mógł znaleźć numeru svn.mywebsite.com, szukał po prostu mywebsite.com. Po połączeniu z serwerem "A", w którym istnieją rekordy virtualhost dla serwera SVN, Apache przejął i udostępnił treść odpowiednią dla svn.mywebsite.com.

Ale w pewnym momencie moja pamięć podręczna DNS została odświeżona i bez logiki aplikacji, która po cichu odesłała użytkownika z powrotem na serwer "A", mój serwer programistyczny rozpoczął rozpoznawanie mywebsite.com na serwerze "B" - gdzie SVN nawet nie został zainstalowany.

Oczywiście, to wtedy, gdy klient SVN zaczął mówić "uh, gee, nie ma takiego serwera". (Kto wiedział to co OPCJE bla bla 200 OK myśli?)

Dlaczego jestem idiotą

Oto gdzie nieuniknione ID10T błędu wchodzi w grę. Powodem, dla którego mogłem konsekwentnie przeglądać "http://svn.mywebsite.com/myrepo" w Firefoksie, było to, że ręcznie utworzyłem wpis hosta na moim komputerze, wskazując adres IP serwera "A".

Gdybym zapamiętał to wcześniej, zaoszczędziłbym wiele czasu – i kilku cennych tabletek Ibuprofenu.:)

Answer 2

Podobny problem tutaj, z inną przyczyną i rozwiązaniem.

Prosta odpowiedź

Downgrade klient Subversion.

Im bardziej skomplikowana odpowiedź

Wcześniej ja używa 1.6.11 (szczególnie 1.6.11-SlikSvn-tag-1.6.11@935062-X64) i że pracował w porządku. Zaktualizowano do wersji 1.6.17 (1.6.17-SlikSvn-tag-1.6.17@1130898-X64), a następnie zaczął się błąd OPTIONS of ... 200 OK. Obniżenie poziomu poprawiło to. Wszystko to było bardziej zagmatwane przez fakt, że (oczywiście) mogłem nadal przeglądać repozytorium w mojej przeglądarce, a także w IntelliJ, które, jak przypuszczam, używa własnego klienta SVN.

Dlaczego jestem idiotą

Ponieważ pracuję na dwóch repozytoria SVN, a drugi współpracuje z obiema wersjami klienta, nie zauważyłem tego problemu dopiero kilka dni po zaktualizowany, więc nie od razu zrozumiałem przyczynę. Gdybym zdał sobie sprawę, że wcześniej, zaoszczędziłbym sobie dużo czasu - choć przestałem tylko uderzać w środki przeciwbólowe!

</bezczelny plagiat odpowiedzi Brian Lacy >

Answer 3

miałem ten problem po uaktualnieniu mojego serwera SVN do 1,7

naprawiłem to przez dodanie następujących do mojego dyrektywy lokalizacji apache:

SVNAdvertiseV2Protocol Off 

Answer 4

Mam ten sam problem, ponieważ próbowałem dodać drugi SVN Repo. Po przeczytaniu tego posta rozpoznałem, że muszę dodać kolejny zestaw Lokalizacja w moim pliku konfiguracyjnym SVN (w moim przypadku: /etc/apache2/mods-enabled/dav_svn.conf) z różnymi ścieżkami. Teraz działa po ponownym uruchomieniu Apache.

Answer 5

Ten błąd "svn: OPTIONS of" może również pojawić się, jeśli twój serwer korzysta z portu svn, ale pod adres URL określasz protokół http.

Oznacza to, że pojawia się błąd, gdy próbowałem:

svn checkout http://genericsite.com/someproject/trunk someproject 

ale to, co powinien był zrobić to:

svn checkout svn://genericsite.com/someproject/trunk someproject 

Answer 6

Dlaczego nie jedno rozwiązanie dla śmiesznie niejednoznacznej błędu wiadomość? W moim przypadku repozytorium SVN zostało utworzone przez użytkownika root, więc uprawnienia były nieprawidłowe.

chown -R apache:apache /var/www/svn/foo 

A ponieważ biegnę SELinux, zrobiłem to również środek na dobre: ​​

chcon -R system_u:object_r:httpd_sys_content_t:s0 /var/www/svn/foo 

ETA:

łatwy do wykrycia objawem tego problemu jest w logach Apache .Uwaga, nie ciało wysłany w odpowiedzi na żądanie opcji:

"OPTIONS /rancid HTTP/1.1" 200 - "-" "SVN/1.6.11 (r934486) neon/0.29.3" 

Po zmianach:

"OPTIONS /rancid HTTP/1.1" 200 97 "-" "SVN/1.6.11 (r934486) neon/0.29.3"