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.