Windows 2012 VisualSVN kann nicht mit dem Linux Subversion Client verbunden werden

1143
Scott Bonner

Ich versuche, den Subversion-Client auf einem Red Hat-Computer mit einem Windows Server 2012-Computer zu verbinden, auf dem VisualSVN Server ausgeführt wird. Mein Ziel ist es, svn exportein Shell-Skript auf dem Linux-Rechner auszuführen, um Code für den Entwicklungsserver abzurufen.

Zuerst habe ich versucht, eine Verbindung mit der Standard-https Repo-Verbindungszeichenfolge herzustellen.

svn export --username user --password pass https://OPSSVN1/svn/volunteers/ ./svn-export

die Linux-Box kehrt zurück ...

svn: Server sent unexpected return value (501 Not Implemented) in response to OPTIONS request for 'https://OPSSVN1/volunteers'

Also habe ich svnserve.exe als Dienst installiert und auf 3960 installiert und das Skript in .. geändert.

svn export --username user --password pass svn://OPSSVN1:3960/volunteers/ ./svn-export

Ich erhalte die folgende Nachricht

svn: Can't connect to host 'OPSSVN1': Connection refused

Wenn ich nun eine Verbindungszeichenfolge vom Desktop eines Fensters aus verwende, funktioniert das einwandfrei.

Andere bekannte Fakten, die helfen könnten ...

  • Der Windows-Server hat die Firewall für den Port geöffnet.
  • Die Linux-Box kann die Maschine anpingen
  • Die Linux-Box kann Telnet in Port 443 der Windows-Box
  • Die Linux-Box kann nicht in Port 3960 der Windows-Box telnet
  • Linux-SVN-Version: svn, Version 1.6.11 (r934486)
  • VisualSVN Version 2.7.2

Der SVN-Dienst, den ich unter Windows eingerichtet habe, wurde mit dem folgenden Befehl ausgeführt.

cmd /c sc create subversion binpath="c:\svnserve\svnserve.exe --service -r E:\Repositories --listen-port 3960"

Der Ordner svnserve ist eine symbolische Verknüpfung zum bin-Ordner von visualsvn, der sich im x86-Verzeichnis der Programmdateien befindet.

Irgendwelche Ideen, wie ich diese Linux-Box dazu bringen kann, den Code aus VisualSVN zu exportieren?

1
Gefunden, dass dies wahrscheinlich ein Linux-Problem sein wird. Der Server, von dem ich das ausprobiert habe, hat ihm nicht gefallen. Ein anderer Server, der ähnlich ist, hat gut funktioniert. Sie haben die gleiche Version installiert. Ich begrüße alle Gedanken. Scott Bonner vor 10 Jahren 0

1 Antwort auf die Frage

0
bahrep

  1. Es sieht so aus, als ob Sie eine ungültige URL eingeben.

    Woher hast du die URL https://OPSSVN1/volunteers/? URLs von VisualSVN Server-Repositorys sehen normalerweise so aus https://<hostname>/svn/<repository-name>. In Ihrem Fall muss die URL sein, es https://OPSSVN1/svn/volunteers/sei denn, Sie verstecken den VisualSVN-Server hinter einem Reverse-Proxy.

  2. Sie verwenden einen zu veralteten Subversion 1.6.11-Client auf einem Linux-Computer.

    Subversion 1.6 wird ab Version 1.8 nicht mehr unterstützt. Die jeweilige Version 1.6.11 wurde am 19. April 2010 veröffentlicht und ist zu veraltet. Es ist tatsächlich hinter 11 Patch-Releases. Der neueste Subversion 1.6.23-Client wurde am 30. Mai 2013 veröffentlicht und enthält zahlreiche Korrekturen. Wenn Sie den svn 1.6-Client verwenden müssen, aktualisieren Sie ihn dann mindestens auf die neueste Patch-Version.

    Auf der anderen Seite müssen Sie erwägen, Ihre Clients auf die neueste Version von Subversion 1.8 zu aktualisieren .

1. Das https: // OPSSVN1 / volunteers / url war darauf zurückzuführen, dass der svnserve-Dienst, der Port 3960 überwacht, die Dateien finden soll. Die typische svn-URL für svn funktioniert nicht, wenn svn: // verwendet wird. Sie haben Recht damit, dass / svn / genau das ist, was der erste Versuch tatsächlich hatte. Ich habe den zweiten Versuch kopiert und für den Beitrag modifiziert, also Ich werde es bearbeiten. Scott Bonner vor 10 Jahren 0
2. Was ungerade ist, ist auf einem Linux-Server, bei dem genau dasselbe svn installiert ist, wird mir eine Verbindung verweigert und die andere funktioniert. Scott Bonner vor 10 Jahren 0
@isisgate, VisualSVN Server unterstützt nicht die Verwendung von `svnserve`. Kombinieren Sie die Problembehandlung nicht, da Sie bei der Verwendung von HTTP (S) das ursprüngliche Problem untersuchen müssen. `svnserve` ist eine andere Geschichte, und es würde nicht helfen, dieses Verhalten zu beheben, würde ich sagen. bahrep vor 10 Jahren 0
Denken Sie, dass die Aktualisierung der svn auf der Linux-Box die https-Version in Ordnung bringen wird? Scott Bonner vor 10 Jahren 0
@Isisgate kann **, aber ich kann es nicht mit Sicherheit sagen. Probieren Sie das neueste svn 1.6.23, 1.7.16 und 1.8.8 aus: http://subversion.apache.org/packages.html bahrep vor 10 Jahren 0
Ich werde ein "yum update svn" auf dem Problemserver ausführen und sehen, was passiert. Scott Bonner vor 10 Jahren 0
yeah sieht aus wie das Dateisystem ein wenig abgespritzt ist. Alles ist im Nur-Lese-Modus, von dem ich nur ahnen kann, dass es wegen e2fsck laufen muss. Daher kann ich kein RPM auf der Maschine über sftp oder wget erhalten, um dies zu versuchen. Muss bis Montag warten, wenn sich eine Person mit VMware-Zugriff befindet, um vorab einen Schnappschuss der Maschine zu erhalten. Scott Bonner vor 10 Jahren 0

Verwandte Probleme