So, wie die Konversion in der Theorie abläuft, wissen wir jetzt. In der Praxis allerdings hat bei mir die Konversion erstmal gar nicht geklappt, weil ich in der Vergangenheit in meinem cvs-Repository wohl mitunter ein bißchen geschlampt habe. Bevor ich nämlich überhaupt erst die neue Hardware hatte, habe ich erstmal die Konversion auf einer Windows Box getestet und mußte dabei einige Überraschungen feststellen:

Subversion unter Windows

Für Windows gibt es einen sehr einfach zu handhabenden Subversion-Server, der einen Apache gleich mitbringt und alles in einem Rutsch installiert: VisualSVN Server. Dazu installiert man sich nur noch eine aktuelle Python Version (für cvs2svn) und den überragenden Subversion Client Tortoise SVN, dann kann ein erster Test losgehen.

Konversion durchführen

Meine cvs-Dateien liegen bei meinen Tests unter c:\temp\cvs und das anzulegende Repository liegt unter c:\repositories\cvs. In meinem Beispiel liegt die Python-Installation unter c:\python25 und der VisualSVN Server unter "c:\Program Files\VisualSVN Server". Dummerweise kann das Python-Skript cvs2svn nicht mit Spaces in Dateinamen umgehen, auch wenn man sie ordentlich quotet, weswegen man von den Installationen erstmal die kurzen Dateinamen ermitteln muss. Und um auszuprobieren, ob die Konversion überhaupt klappen kann, kann man die Konversion auch mit dem Parameter --dry-run laufen lassen, um zu sehen, welche Probleme das Skript bei der Konversion hat.

Bei mir lautet die Kommandozeile dann folgendermaßen:

c:\python25\python.exe cvs2svn  --dry-run --svnadmin=c:\Progra~1\Visual~2\bin\svnadmin.exe --svnrepos c:\repositories\cvs c:\temp\cvs

Und wenn das dann auf meinem alten Pentium III so 10 Minuten läuft, zeigt sich auch schon, daß ich in der Vergangenheit geschlampt habe, denn es erscheint folgende Fehlermeldung:

----- pass 2 (CollateSymbolsPass) -----
ERROR: It is not clear how the following symbols should be converted.
Use --force-tag, --force-branch, --exclude, and/or --symbol-default to
resolve the ambiguity.
    'SU_V2_CODEBASE' is a tag in 4 files, a branch in 1471 files and has commits in 74 files

Für die überwiegende Zahl an Dateien war in meinem CVS also SU_V2_CODEBASE ein Branch und kein Tag, weswegen ich mit einer Modifikation der Kommandozeile schließlich einen sauberen Testlauf schaffe:

c:\python25\python.exe cvs2svn  --dry-run  --force-branch=SU_V2_CODEBASE --svnadmin=c:\Progra~1\Visual~2\bin\svnadmin.exe --svnrepos c:\repositories\cvs c:\temp\cvs

Dieser Konversionslauf läuft dann ungefähr 15 Minuten, aber wird dann ohne Fehler beendet, weshalb jetzt der echte Konversionslauf folgen kann:

c:\python25\python.exe cvs2svn  --force-branch=SU_V2_CODEBASE --svnadmin=c:\Progra~1\Visual~2\bin\svnadmin.exe --svnrepos c:\repositories\cvs c:\temp\cvs

Und nach gut einer halben Stunde ist das konvertierte Repository komplett angelegt. Um das Ganze auszuprobieren geben wir nun folgenden URL im Webclient unserer Wahl an:

http://127.0.0.1:8080/svn/cvs/trunk/

Wir werden dann nach einem Benutzernamen gepromptet und sehen das Repository im Browser. Die 8080 ist dabei der Default-Port den VisualSVN verwendet.

War's das nun?

Wer sich jetzt am Ziel wähnt, der sollte an dieser Stelle mal einen vollständigen Checkout seines CVS-Repositories und seines neuen SVN-Repositories machen und einen Binärvergleich machen. Das machen wir dann beim nächsten Mal und ich werde dabei zeigen welche letzten Hürden es zu nehmen gilt für die möglichst optimale Konversion von cvs zu svn.

So wir haben also nun einen Rechner bereitstehen, auf dem später das Subversion-Repository liegen soll. Subversion setzt einen laufenden Apache Webserver voraus, also müssen wir erstmal den Apache, dann die Libraries, die Subversion vom Apache braucht, und schließlich Subversion selbst installieren:

sudo apt-get install apache2
sudo apt-get install libapache2-svn
sudo apt-get install subversion

Als nächstes müssen wir die WebDAV-Konfiguration von Subversion anpassen. Dazu öffnen wir die Konfiguration im Editor:

sudo gedit /etc/apache2/mods-enabled/dav_svn.conf

Ich will erstmal ein SVN-Repository, bestehend aus meinem importierten alten cvs-Repository haben, aber vielleicht später mal weitere davon unabhängige Repositories. Daher befreie ich den Location-Tag in der Datei erstmal von seinem vorangestellten Kommentarzeichen, so daß er folgendermaßen ausschaut:

<Location /svn >

Und bei der Gelegenheit machen wir das Entfernen des vorangestellten Kommentarzeichens auch fuer den schließenden </Location>-Tag weiter unten in der Datei, sonst beschwert sich der Apache beim nächsten Start.

Die nächste Zeile muß dann auch noch vom vorangestellten Kommentarzeichen befreit werden:

DAV svn

Weil ich mehrere Repositories unter dem Verzeichnis /svn haben will, lege ich auch noch folgende Zeile an:

SVNParentPath /svn

Für mein Heimnetzwerk genügt es vollauf, mit Basic Auth zu arbeiten, denn der einzige, der hier auf der Leitung schnüffelt bin ich (toitoitoi!), also werden noch folgende Zeilen von den vorangestellten Kommentarzeichen befreit:

AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd

So, das war's jetzt, wir können die Konfigurationsdatei speichern. Wir legen jetzt das Verzeichnis für die Repositories an:

sudo mkdir /svn

Jetzt legen wir noch einen User (im Beispiel "svnuser") für den Zugriff auf die Repositories an:

sudo htpasswd -cm /etc/apache2/dav_svn.passwd svnuser

Und starten den Apache neu:

sudo /etc/init.d/apache2 restart

Als nächstes müssen wir irgendwie unser altes cvs auf die neue Maschine bringen. Dazu lege ich ein neues Verzeichnis /cvs an:

sudo mkdir /svn

Und gebe über den Dateibrowser das Verzeichnis frei, wobei gleich der Samba-Server für mich installiert wird. Dann kopiere ich mein letztes cvs-Backup in dieses Share.

Die eigentliche Konversion findet statt mit einem in Python geschriebenen Tool namens cvs2svn, das man sich von der Website von CollabNet herunterladen und dann auspacken muß. Das ruft man dann beispielsweise so auf, wenn man, wie ich, seine cvs-Dateien in /cvs hat und davon ein Repository in /svn/cvs anlegen will:

python cvs2svn --svnrepos /svn/cvs  /cvs

Jedenfalls macht man das so in der Theorie. Und was man in der Praxis beachten muss, davon dann in der nächsten Folge.

Dieses Mal im Weihnachtsurlaub stand der lang ersehnte Umzug meines privaten cvs-Repositories in ein Subversion-Repository auf dem Plan. Nachdem ich das Ganze jetzt erfolgreich hinter mich gebracht habe, will ich kurz darüber berichten. Nur für den Fall, daß ich das nochmal irgendwo machen muß, oder jemand vor denselben Problemen steht wie ich.

Hardwarebeschaffung

Mein derzeitiges cvs hausiert seit nunmehr über 5 Jahren auf einem alten Pentium 133 mit 64 MB Speicher auf dem ein Dead-Rat Linux 7.2 ("Enigma") tickert. Ja, ein schnarchlahmes Baby-AT-Board von 1996 in einem dröhnenden Colani-Design-Tower und mit einem OS, für das es seit über 4 Jahren kein Update mehr gibt. Klar, daß also erstmal zeitgemäße Hardware beschafft werden muß, denn auf der Hardware läuft sicher kein modernes Linux mehr. Mal davon abgesehen, daß die Hardware wirklich keine Zierde mehr ist, selbst in meinem, an Bizarrerien und Absurditäten sonst so reichen Hardware-Zoo.

Die zeitgemäße Hardware ist ein Intel D201GLY2-Board. Das ist ein superbilliges Micro-ATX-Board mit aufgelötetem, lüfterlosen Celeron 220 Prozessor (Conroe-Kern, also keine NetBurst-Architektur) und mit allem on-board, was man so braucht (AC97, 100 MBit LAN, VGA, 6 x USB 2.0, 1 x PCI, 2 x SATA, 1 x PATA). Das beste ist aber der Preis: Das Board kostet gerade mal 55 Euronen. Ursprünglich für den "Sub-Value-Market" (sprich: Entwicklungs- und Schwellenländer) konzipiert, sollte das Board hierzulande gar nicht erst in den Verkauf kommen, aber es ist doch in nennenswerten Stückzahlen bei hiesigen Versendern zu bekommen. Zusammen mit einem Micro-ATX-Gehäuse, einer 250GB SATA-Festplatte und einem DVD-ROM und 1 GB guten Kingston Speichers (das ist der Vollausbau für das Board) betrugen die Kosten inklusive P0rno und Verpackung und Nachnahmegebühren genau 205,90 Euro. Testhalber habe ich auf das Ding nach dem Zusammenbau mal ein XP x86 aufgespielt und man kann tatsächlich mit dieser Hardware locker DVDs anschauen ohne dass irgendwas ruckelt oder der Prozessor mächtig rudern müßte. Ein Blick ins BIOS offenbart, daß das Board auch Intel EM64T-Unterstützung bietet. Also spaßeshalber ein XP x64 aufgespielt und alles läuft, nicht ein Treiber, der nicht aufzutreiben wäre. Nur schade, daß VMWare auf dem Prozessor keine x64-Gastsysteme laufen läßt, sonst wäre die Hardware sogar ein echt heißer Kandidat für einen privaten VMWare-Server.

Aber jetzt schnell wieder das böse, böse XP weggeputzt und Ubuntu 7.10 ("Gutsy Gibbon") aufgespielt. Das scheint auch erst mal ganz gut zu funktionieren, bis X-Windows mit der erkannten Grafikkarte loslaufen will. Dann sieht man nur noch Geisterbilder und Schlieren auf dem Desktop. Gluecklicherweise kann man es aber noch so lala bedienen und erkennen was man tut. Flugs also ein

sudo dpkg-reconfigure xserver-xorg

aufgerufen, den VESA-Treiber selektiert und schon ist alles gut.

So, die Hardware läuft und ein OS ist drauf. Beim nächsten Mal schreibe ich, was man machen muß um darauf Subversion zu installieren und wie man sein CVS- in ein SVN-Repository umwandeln kann. Dort gibt es einige Probleme und ich werde zeigen, wie ich sie umschifft habe. Zu guter letzt werde ich zeigen, wie ich mein Repository backuppe und es gegebenenfalls wieder zurückspielen kann.

Am Freitag, 21.12.2007 spielt die Bow Tie Bigband, featuring Sabine Petrich, ab 21h in der Jazz Hall in Stuttgart mit dem Programm 'XMas Reloaded'. Für mich ist es der achte Gig dieses Jahr mit der Bow Tie und jedesmal war es ein Mordsspaß. Die Jazz Hall (ehemals 'Dixieland Hall') ist mitten in Stuttgart, in der Marienstraße 3, bequem vom S-Bahnhof Stadtmitte in 5 Gehminuten zu erreichen. Einlaß ist ab 20h, wieviel Eintritt weiß ich nicht, ich schätze mal so um die 10 Euronen.

Update 11/20/2007: Der Gig fängt schon um 20.15h an, nicht erst um 21h. Außerdem soll der Eintritt auch sich eher im Bereich 6-8 Euro bewegen.