it-swarm.com.de

Repo-Verbindung mit TortoiseSVN nicht möglich

Ich habe seit einigen Monaten ein Projekt mit demselben TortoiseSVN-Repository ohne viel Aufwand ausgeführt.

Ich muss dem Projekt eine weitere Box hinzufügen, aber es scheint für TSVN unmöglich zu sein, eine Verbindung zum Repository herzustellen. Das ist das, was ich entdeckt oder ausprobiert habe:

Ich habe zwei Client-Boxen: die "alte" und die "neue" ...

  1. Das Einrichten und Auschecken eines zweiten Ordners in der "alten" Box funktioniert gut.
  2. Das Durchsuchen des Repos über Chrome/IE in der "neuen" Box funktioniert ebenfalls einwandfrei.
  3. Die Browser in meiner "neuen" Box verwenden keinen Proxy (das gleiche gilt für die "alte" Box).
  4. Ich verwende TSVN 1.7.4, Build 22459 - 64 Bit auf beiden Boxen
  5. Wenn ich versuche, eine Verbindung zum Repo aus dem "neuen" Feld mithilfe des Repo-Browsers herzustellen oder in einen neuen Ordner auszuchecken, erhalte ich diese Fehlermeldung: 

    Keine Verbindung zu einem Repository unter URL 'Https: // (IP-Adresse nicht angegeben)/usvn/svn/(Projekt nicht angegeben)' OPTIONS von 'https: // (IP-Adresse nicht angegeben)/usvn/svn/(Projekt wurde ausgelassen) ': konnte nicht Verbindung zum Server (IP-Adresse nicht angegeben)

  6. Ich habe alle TSVN-Einstellungen zwischen den "neuen" und "alten" Kästchen verglichen und sie scheinen alle zusammenzupassen

  7. Laut den Personen, die den Server betreiben, werden keine Zertifikate verwendet
  8. Die Windows-Firewall in der "neuen" Box ist inaktiv
  9. Ich verwende "alte" und "neue" Box aus demselben Netzwerk. Das "Alte" ist jedoch über WIFI verbunden, während das "Neue" drahtgebunden ist.

Ich bin am Ende, was zu prüfen ist, so dass alle Hinweise sehr geschätzt werden.

Vielen Dank

14
Jonas Rembratt

Sie müssen feststellen, ob dies ein Problem mit TortoiseSVN, Ihrem Subversion-Repository oder Ihrer Netzwerkverbindung ist.

  • Überprüfen Sie zunächst Ihre URL. Ich habe nie benutzerfreundliches SVN verwendet, daher weiß ich nicht, was es mit der Apache-HTTPd-Konfiguration macht. Die Apache-Standardkonfiguration für mehrere Repositorys lautet jedoch normalerweise http://<server>/svn/<module> und nicht http://<server>/svn/usvn/<module>. Ist das /usvn/-Verzeichnis dort vorhanden?
    • Wie wurde Apache übrigens konfiguriert? Übernimmt das benutzerfreundliche SVN auch, oder können Sie lediglich die Repositorys konfigurieren? Verwenden Sie Visual-SVN oder hat jemand Apache httpd manuell konfiguriert?
  • Wenn die URL korrekt ist, versuchen Sie es mit einem Ping an Ihren Subversion-Server. Können Sie es von Ihrer Windows-Box aus anpingen? Wenn nicht, haben Sie ein Netzwerkproblem. Aus irgendeinem Grund ist die IP-Adresse von Ihrer Client-Box nicht erreichbar.
  • Versuchen Sie, einen Browser zu öffnen, und fügen Sie die URL des Subversion-Repositorys in das Fenster ein. Das sollte funktionieren. Wenn dies der Fall ist, liegt das Problem wahrscheinlich bei TortoiseSVN. Laden Sie einen Subversion-Client für die Befehlszeile herunter und prüfen Sie, ob Sie damit auschecken können.
  • Verwenden Sie dieselbe URL in einer anderen Box. Können Sie von dort aus checken? Wenn ja, deutet dies auf ein Problem mit dem Netzwerk hin.
13
David W.

Löschen Sie die Einstellungen unter "Gespeicherte Daten" - siehe:

http://tortoisesvn.net/docs/release/TortoiseSVN_de/tsvn-dug-settings.html

Das funktionierte für mich mit Windows 7.

Eric

12
user2753722

Ich habe festgestellt, dass das Ersetzen des ersten Teils der URL durch IP-Adressnummern anstelle von Wörtern für mich funktioniert hat.

Zum Beispiel verwenden Sie:

http://111.11.11.111/svn/Directory

anstatt:

http://www.url.com/svn/Directory
4
Wes

Ich habe mit genau demselben Problem gekämpft. Ich habe meinen Arbeitslaptop ersetzt und plötzlich habe ich keine Verbindung mehr zum Server. Seltsamerweise bekam ich zu Beginn nur Fehler, die mich daran hinderten, zu begehen, wie: Befehl: Commit Fehler: Commit fehlgeschlagen (Details folgen): Fehler: MKACTIVITY von '/ svn //! svn/act/c511b853-23b4-db4a-8991-0bc689a63353 ': Fehler: Die Antwortstatuszeile konnte nicht analysiert werden (http: // * .* *. com) Abgeschlossen ! : 

Als ich in eine andere Filiale wechselte (der SVN-Server war für jeden in beiden Filialen ohne Probleme zugänglich, der über die richtige Sicherheit verfügt), bekam ich eine Fehlermeldung wie:

Befehl: Checkout von http: //.com/svn/fineos/ /trunk, Revision HEAD, Vollständig rekursiv, Externe enthalten Fehler: Verbindung zu a kann nicht hergestellt werden Repository unter URL Fehler: 'http: // * * . com/svn/fineos */* / trunk' Fehler: OPTIONEN von Fehler : 'http: // * . com/svn/fineos */* / trunk': könnte Fehler: Keine Verbindung zum Server (http: // * . com) Abgeschlossen! : 

Hinweis: In jedem Fall konnte ich über den Browser auf das Repository zugreifen, und es funktionierte für alle anderen. Daher war es offensichtlich kein Netzwerk- oder Repository-Problem. 

Für mich funktionierte es, Tortoise-Client zu deinstallieren und Tortoise-Cache-Ordner aus den Ordnern Local und Roaming unter C:\Users\zu entfernen.nutzer\Anwendungsdaten. Außerdem habe ich den TortoiseSVN-Knoten in der Windows-Registrierung umbenannt, so dass die alte Konfiguration nicht gefunden werden kann . Nach der Neuinstallation ist der Client mit dem Repo-System verbunden. Ich bin mir nicht sicher, ob beide Schritte erforderlich sind. Vielleicht reicht es aus, die Registrierung zu ändern. Das überlasse ich Ihnen. 

Entschuldigung für eine lange Antwort, aber da ich nach längerem Googeln keine Reaktion auf dieses Problem gesehen habe, dachte ich, dass dies für verschiedene Fälle hilfreich sein könnte. 

2
Tomasz

SVN unterscheidet zwischen Groß- und Kleinschreibung. Stellen Sie sicher, dass Sie es richtig buchstabieren. Wenn es umbenannt wurde, können Sie den Arbeitsordner an die neue URL verschieben. Siehe https://tortoisesvn.net/docs/release/TortoiseSVN_de/tsvn-dug-relocate.html

1
as9876

Einmal stand ich vor dem gleichen Problem. Ich habe versucht, svn Checkout mit einer Repository-URL durchzuführen, die aus DOMAIN NAME besteht. Ich habe versucht, mithilfe der IP-Adresse anstelle von DOMAIN NAME eine Verbindung herzustellen, und konnte den Checkout durchführen

0
Vishal Aggarwal

Wie von David W. "Zunächst einmal, überprüfen Sie Ihre URL". Verbindung über IP statt über URL, wie Wes behauptete, funktionierte - (Jetzt müssen wir unsere DNS korrigieren) 

0
Tom A

Schauen Sie sich auch das an: 

Problem: Nach dem Aufrufen von SVN in der Befehlszeile auf einem Server mit Firewall wird 15 Sekunden lang nichts sichtbar angezeigt. Anschließend wird das Programm mit dem folgenden Fehler beendet: 

svn: E170013: Verbindung zu einem Repository unter der URL 'SVN.REPOSITORY.REDACTED' kann nicht hergestellt werden

svn: E730054: Fehler beim Ausführen des Kontextes: Eine vorhandene Verbindung wurde vom Remote-Host zwangsweise geschlossen.

Untersuchung: Die Internetrecherche zu den oben genannten Fehlern ergab keine relevanten Informationen.

Process Tracing (procmon) zeigte einen Verbindungsversuch zu einem Akamai-Server (Cloud Services) nach dem SSL/TLS-Handshake zum SVN-Server. Der Hostname für den Server wurde in der Prozessablaufverfolgung nicht angezeigt. Reverse DNS Lookup zeigte a184-51-112-88.deploy.static.akamaitechnologies.com oder a184-51-112-80.deploy.static.akamaitechnologies.com als Hostnamen an, und die IP-Adresse war entweder 184.51.112.88 oder 184.51. 112.80 (2 Einträge im DNS-Cache).

Das Paketaufnahmetool (MMA) zeigte einen Verbindungsversuch zum Hostnamen ctldl.windowsupdate.com nach dem SSL/TLS-Handshake zum SVN-Server an.

Die Windows Crypto-API hat versucht, eine Verbindung zu Windows Update herzustellen, um Zertifikatsperrinformationen (CRL - Certificate Revocation List) abzurufen. Das Standardzeitlimit für den Abruf der CRL beträgt 15 Sekunden. Das Zeitlimit für die Authentifizierung auf dem Server beträgt 10 Sekunden. da 15 größer als 10 ist, schlägt dies fehl. 

Resolution: Bei der Internetrecherche wurde Folgendes entdeckt: (siehe auch Bild unten)

Lösung 1: Verringern des CRL-Zeitlimits Gruppenrichtlinien -> Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Richtlinien für öffentliche Schlüssel -> Einstellungen für die Überprüfung des Zertifikatpfads -> Netzwerkabruf - siehe folgende Abbildung.

https://Subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698

support.Microsoft.com/de-de/kb/2625048

blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx

Lösung 2: Öffnen Sie die Firewall für den CRL-Verkehr

support.Microsoft.com/de-de/kb/2677070

Lösung 3: SVN-Befehlszeilenflaggen (nicht getestet)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - Alternative svn-Befehlszeilenflagge.

Zusätzliche Informationen: Das Debuggen dieses Problems war besonders schwierig. SVN 1.8 hat die Unterstützung der Neon-HTTP-RA-Bibliothek (Repository-Zugriff) zugunsten der Serf-Bibliothek deaktiviert, durch die die Debugprotokollierung für Clients entfernt wurde. [1] Außerdem stimmte der zurückgegebene SVN-Fehlercode nicht mit der in svn_error_codes.h angegebenen Zeichenfolge überein. [2] Außerdem können SVN-Fehlercodes nicht einfach auf ihr ENUM-Label zurückgegeben werden. In diesem Fall ordnet der SVN-Fehlercode E170013 SVN_ERR_RA_CANNOT_CREATE_SESSION zu.

  1. stackoverflow.com/questions/8416989/isit-moglich-zum-ziel-svn-client-debug-output
  2. people.Apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
  3. code.google.com/archive/p/serf/issues/172

Vorgeschlagene SVN-Änderungen: 

  1. Aktivieren Sie die Ausführlichkeit des Befehls wie für alle Vorgänge

  2. Fügen Sie den Fehler-ENUM-Namen zu stderr hinzu

  3. Konfigurations-Flag für die Debug-Protokollierung der Serf Library hinzufügen.

0
Cameron Sours