Mercurial und Subversion

Letzte Änderung am 22. April 2017 by Christoph Jüngling

Da ein aktuelles Projekt fast seit Beginn der Arbeiten in Subversion verwaltet wird, es jedoch gewisse Hemmnisse gibt, die recht alte Serversoftware zu aktualisieren, hat das Team darüber nachgedacht, eine andere Quellcodeverwaltung einzusetzen. Spätestens seit diesem Artikel ist Mercurial dabei an vorderster Stelle in der Diskussion. Was also liegt näher als zu versuchen, das Subversion-Repository nach Mercurial zu clonen?

Zunächst einmal fiel die Entscheidung, die Mercurial-Extension hgsubversion zu verwenden. Diese wird in TortoiseHg über den Einstellungsdialog oder direkt in der Datei %userprofile%\mercurial.ini aktiviert (selbstverständlich muss der korrekte Pfad eingetragen werden):

[extensions]
hgsubversion = C:\Programme\TortoiseHg\hgsubversion\hgsubversion

So naheliegend der Gedanke ist, so schwer ist er in die Tat umzusetzen. Denn der recht alte SVN-Server verweigerte sich bislang standhaft allen Versuchen, seine Historie vollends herauszugeben.

Also habe ich es zunächst mal mit einem anderen, aktuelleren SVN-Server versucht, und zwar dem Testserver der Access-Codelib. Hier ergab sich erstmal ein ganz anderes Problem, nämlich das abgelaufene SSL-Zertifikat, das Mercurial zu Recht bemängelt:

C:\> hg clone --verbose -- svn+https://svn.access-codelib.net/svn/test/ .
abort: Failed to open Subversion repository; please try running 'svn ls https://svn.access-codelib.net/svn/test' for details.
[command returned code 255 Fri Dec 30 14:39:21 2011]

Die Empfehlung, die ich hier rot markiert habe, ist sehr hilfreich, denn leider verrät TortoiseHg nicht, dass es sich um ein Zertifikatproblem handelt. Um aber den angegebenen Konsolenbefehl ausführen zu können, muss zunächst auch der SVN-Client installiert werden. Das geht am einfachsten durch die Installation von TortoiseSVN. Danach liefert der angegebene Befehl mehr Informationen (das Wichtigste wieder in rot):

C:\> svn ls https://svn.access-codelib.net/svn/test
Error validating server certificate for 'https://svn.access-odelib.net:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!

- The certificate has expired.
Certificate information:
- Hostname: svn.access-codelib.net
- Valid: from Thu, 02 Dec 2010 23:00:00 GMT until Sat, 03 Dec 2011 22:59:59 GMT

– Issuer: Comodo CA Limited, Salford, Greater Manchester, GB
– Fingerprint: f2:0d:5d:9d:95:07:9e:4c:44:ff:55:db:c8:02:c2:3b:48:b0:e5:10
(R)eject, accept (t)emporarily or accept (p)ermanently?

Es ist nötig, diesen Fingerprint auch für SVN mit “p” zu bestätigen! Und mit diesen Informationen ist es nicht mehr schwer, Mercurial zum Arbeiten zu überreden:

Initialisiere das lokale Repository, lege im Unterverzeichnis .hg eine Datei hgrc an und öffne diese zum Bearbeiten. Nun füge folgende Zeilen ein:

[paths]
default = svn+https:///svn.access-codelib.net/svn/test

[hostfingerprints]
svn.access-codelib.net = f2:0d:5d:9d:95:07:9e:4c:44:ff:55:db:c8:02:c2:3b:48:b0:e5:10

Nun sollte es gehen. Es versteht sich aber hoffentlich von selbst, dass man vor allen diesen Aktionen die Gültigkeit des Zertifikats überprüft. Zum Beispiel kann man den Betreiber des SVN-Servers bitten, uns diesen Fingerprint zuzuschicken (oder am Telefon vorzulesen). Ansonsten könnte es passieren, dass sich jemand anderer dazwischengemogelt hat (man-in-the-middle-attack), und dem will man es ja nicht zu einfach machen :-)

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

zwölf − 12 =