Versionsmanagement für Anfänger

Heute schreibe ich mal das auf, was ich mir letzte Woche an einem Abend bis tief in die Nacht hinein mühsam erkämpft habe, nämlich wie man als unbedarfter Jungspund-Programmierer in die Geheimnisse der automatischen Versionsverwaltung mit CVS oder SVN vordringt!

Das Problem ist schnell umrissen: Ich kann schlecht jede Woche eine neue Version meiner Loudblog Software rausbringen, da jeder offizielle Release mit einem gewissen Aufwand verbunden ist. Außerdem ist es nicht nett, von allen Usern ständig zu verlangen, ihre Installationen auf den neuesten Stand zu bringen. Aus diesem Grund gibt es offizielle Releases von Loudblog immer nur dann, wenn es wirklich neue Features gibt, die entweder revolutionär oder auch einfach nur praktisch sind.

Dennoch gibt es einige User, die gerne öfters auch mal eine inoffizielle Zwischenversion hätten. Und eigentlich spricht auch gar nichts dagegen, denn solange man nicht größere Generalumbauten am Quellcode vornimmt, ist der aktuelle »Entwicklungsbaum« (Baum hier im Sinne von Ordnerstruktur) stets lauffähig. Doch kann man natürlich schlecht den Leuten die neuesten Dateien mit den frischen Bugfixes einzeln per Mail zuschicken. Was also tun?

Ganz klar: Versionsmanagement. Das klingt furchtbar kompliziert, und ist es intern auch. Doch in der praktischen Anwendung sind das an sich nicht mehr als ein paar Mausklicks zusätzlich, und die aktuellste Entwicklungsversion (»nightly build«) ist auch im Internet für alle Interessenten abzugreifen. Zumindest für die, die sich mit dem Kram auskennen :-)

Wie geht das vor sich? Ich beschreibe hier, wie man unter Mac OS X eine SVN-Versionsverwaltung einrichtet. Natürlich gibt es andere Methoden und sogar andere Betriebssysteme, aber da weiß ich nicht drüber Bescheid, also lass ich das sein.

Zunächst einmal muss mein Computer SVN-fähig werden. SVN ist die Abkürzung für Subversion und das ist die Technik, auf der alles basiert. (SVN gilt als der Nachfolger von CVS.) Glücklicherweise gibt es für Mac OS X eine vorkompilierte Version, die Martin Ott von den Coding Monkey als pflegeleichtes .dmg verpackt hat. Dankeschön, so muss man nicht mit der Kommandozeile oder gar Fink rumschwurbeln. Einfach installieren – und sich dann wundern, dass nichts passiert. Denn SVN arbeitet unsichtbar. Aber es tut tatsächlich was, nämlich mitprotokollieren! Dazu gleich mehr.

Nun müssen wir uns einen Internet-Server suchen, der SVN unterstützt. Gar nicht so einfach, denn es handelt sich nicht um eine fluffige PHP-Lösung, die man einfach auf seinen Webspace schiebt und fertig. Wer wie die meisten Leute keinen Dedicated Server besitzt, muss eine gehostete Lösung nutzen. Zum Glück gibt es einige kostenlose Anbieter. Eine Liste findet sich hier. Ich habe mich für OpenSVC entschieden, weil hier mein Verzeichnis in 10 Minuten automatisch freigeschaltet und nicht erst von einem Mitarbeiter überprüft wird.

Doch wie bekomme ich mein Projekt auf diesen Server? Einen FTP- oder Web-Zugang suche ich vergeblich! Ganz einfach: Nun laden wir uns svnX herunter, was im Großen und Ganzen eine grafische Benutzeroberfläche für SVN ist und uns eine ganze Menge Ärger abnimmt. Beim ersten Start fragt svnX uns nach den Zugangsdaten für »Repository« und »Working Copy«. Und nun dringen wir zum Kern der ganzen Geschichte vor: Mit SVN kann ich alle Veränderungen, die ich auf meinem lokalen Rechner (Working Copy) vornehme, auf dem öffentlichen SVN-Server (Repository) synchronisieren. Dabei werden alle Aktivitäten mitprotokolliert und gespeichert, so dass man jede Änderung auch rückgängig machen kann bzw. Zugriff auf jede einzelne »Zwischenversion« (build) besitzt. Grandios!

Ich gebe also die Zugangsdaten für meinen OpenSVN-Server bei »Repository« ein, und trage mein Loudblog-Arbeitsverzeichnis auf meiner Festplatte als »Working Copy« ein. Und weil ich nun zum ersten Mal mit SVN arbeite, muss ich natürlich erst einmal den aktuellen Stand meines Projektes komplett auf den Server legen. Das geht per Drag&Drop recht simpel.

Ich mache dies aber nur ein einziges Mal! Denn ab jetzt kann ich ganz einfach, wie gewohnt, mein Projekt weiterprogrammieren, und SVN merkt sich im Hintergrund alle Änderungen, die ich an den Dateien vornehme. Ich öffne zwischendurch in svnX meine Working Copy und sehe sofort alle Änderungen sauber aufgelistet. Ich markiere diese und schieße sie auf den Server – fertig: Ein neuer Loudblog-Build ist erschienen und kann von anderen Leuten runtergeladen werden.

Der größte Vorteil von Versionsmanagement ist natürlich, dass ich nicht der einzige bin, der sich beim Server einloggen darf und sich »Working Copies« auf seinen Rechner ziehen kann. Das kann jeder, der die Berechtigung dazu bekommt. Und natürlich kann man auch vom Server auf seine lokale Kopie synchronisieren. So können mehrere Leute an einem Projekt arbeiten und sind auf Knopfdruck alle auf dem gleichen Stand.